Saturday, December 19, 2009
Although most users have established their new login credentials with no trouble, some users are calling the Central Customer Support Unit for assistance. As a result, customer support is experiencing high call volume, and many customers are waiting on hold longer than usual.
We apologize for any inconvenience this may cause. We are doing everything possible to remedy this situation.
Tuesday, November 10, 2009
Monday, November 9, 2009
It is, however, practically impossible to know with reasonable certainty whether a new software product could be said to infringe some prior software patent. Patents are conventionally referred to as intellectual property. However, as James Bessen and Michael Meurer have explained in detail, patents differ substantially from tangible property in that their boundaries are often fuzzy and unpredictable. If patents do not give clear notice of their limits, they create a risk of inadvertent infringement. Vague patents also enable opportunistic behavior. For example, a patentee may, based on vague language, claim ownership of a technology unknown to the inventor, but instead first conceived by someone else.This problem of uncertain patent boundaries is particularly acute with software patents. Software is an abstract technology. Software algorithms can be represented in numerous different ways, and even computer scientists sometimes disagree over whether two software technologies are equivalent. Thus it is not surprising that software patents are typically framed in abstract language with uncertain boundaries. As a result, a software developer, when shown a software patent, often cannot be sure whether the patent reads on newly developed code.This difficulty is multiplied hundreds or thousands of times with regard to a complex software product combining hundreds or thousands of discrete components. A separate but related problem faces all software developers—that of the impossibility of patent clearance, or determining whether there are existing patents that may be said to read on a new product. There is no reliable, economical method for searching the hundreds of thousands of existing software patents. The clearance problem is made even worse by the existence of tens of thousands of applications that for eighteen months after filing are unpublished.Thus, simply by virtue of producing and marketing an innovative software product, a software developer assumes the risk of a costly patent infringement lawsuit. In the U.S., software patents are more than twice as likely to be the subject of a lawsuit than other patents and account for one quarter of all patent lawsuits. The cost of defending a patent lawsuit frequently amounts to several million dollars. Such lawsuits involve technical issues that are difficult for judges and juries to understand, and so even with a strong defense the outcome is usually far from certain. If there is a judgment of infringement, the penalty may be an injunction ending further production and enormous monetary damages. Defense costs and litigation risks are so large that in most cases defendants agree to some payment to settle such cases. Even when claims appear to have no valid basis, targets frequently agree to pay for licenses based on the mere threat of litigation.
"In seeking a patent, Bilski and Warsaw told the Patent Office in 1997 that their idea was a highly useful one: using complex mathematical formulas, they could tell a business how to hedge against risk due to the rising and falling of prices of raw materials that were used to produce something — say, to generate electricity. Commodities prices often fluctuate quite widely, because of market forces or even changes in the weather, so these two inventors figured out ways to manage what they called “consumption risk.” It is, they claimed, of benefit both to businesses and to their customers."
Similar, Donald E. Knuth, Professor Emeritus at Stanford University and one of the world’s most respected computer scientists, wrote in 1994, “When I think of the computer programs I require daily to get my own work done, I cannot help but realize that none of them would exist today if software patents had been prevalent in the 1960s and 1970s.” ... Dr. Knuth also stated, “I strongly believe that the recent trend to patenting algorithms is of benefit only to a very small number of attorneys and inventors, while it is seriously harmful to the vast majority of people who want to do useful things with computers.”
Monday, November 2, 2009
Wednesday, September 9, 2009
Monday, August 17, 2009
Should I be concerned about providing my password to GPush?
When we created the app, we committed first and foremost to security. We are using multiple levels of encryption including SSL, obfuscation, and cipher-based encryption. SSL ensures that your credentials can be transported securely. Your login credentials are encrypted using an encryption scheme that has never been cryptographically broken, with a different 'secret key' for each user. To test these security measures, penetration tests were ran on the server with no information accessed.
- Obfuscation: This could mean anything, even that they named sensitive files as grandmasGroceryList.txt to throw off hackers.
- Encryption scheme never been broken: This, again, means nothing. It is some custom scheme that has never been analyzed? I don't want someone's ROT-13 encoder protecting my personal information.
- Different secret key for each user: How are these keys generated and stored? How is this key repository stored to prevent unauthorized access? Is it done in such a way that this is this better (security) than having a single key for each user? Probably not. More than likely, it is just another level of indirection.
- Penetration tests: Professional? Script kiddy? State-sponsored? Automated tools? What level of access was given, and what testing procedures were followed?
Monday, August 3, 2009
Tuesday, July 14, 2009
Monday, May 4, 2009
While 86% of the victims contributed only a single card number, others offered a few more. Of particular interest is the case of a single victim from whom 30 credit card numbers were extracted. Upon manual examination, we discovered that the victim was an agent for an at-home, distributed call center. It seems that the card numbers were those of customers of the company that the agent was working for, and they were being entered into the call center’s central database for order processing.
Monday, April 20, 2009
Apr 19 07:47:30 unknown authpriv.warn dropbear: login attempt for nonexistent user from 184.108.40.206:41238
Apr 19 07:47:31 unknown authpriv.info dropbear: exit before auth: Disconnect received
Apr 19 07:47:31 unknown authpriv.info dropbear: Child connection from 220.127.116.11:42789
Apr 19 07:47:35 unknown authpriv.info dropbear: exit before auth (user 'root', 1 fails): Disconnect received
Apr 19 07:47:35 unknown authpriv.info dropbear: Child connection from 18.104.22.168:44292
Apr 19 07:47:38 unknown authpriv.info dropbear: exit before auth (user 'root', 1 fails): Disconnect received
Apr 19 07:47:39 unknown authpriv.info dropbear: Child connection from 22.214.171.124:45872
Apr 19 07:47:42 unknown authpriv.warn dropbear: login attempt for nonexistent user from 126.96.36.199:45872
Apr 19 07:47:43 unknown authpriv.info dropbear: exit before auth: Disconnect received
Apr 19 07:47:44 unknown authpriv.info dropbear: Child connection from 188.8.131.52:47601
Apr 19 07:47:47 unknown authpriv.warn dropbear: login attempt for nonexistent user from 184.108.40.206:47601
Apr 19 07:47:48 unknown authpriv.info dropbear: exit before auth: Disconnect received
Apr 19 07:47:51 unknown authpriv.info dropbear: Child connection from 220.127.116.11:49411
Apr 19 07:47:54 unknown authpriv.warn dropbear: login attempt for nonexistent user from 18.104.22.168:49411
Apr 19 07:47:55 unknown authpriv.info dropbear: exit before auth: Disconnect received
Wednesday, April 15, 2009
According to the payment-card industry, or PCI, standards for credit card transaction security, PIN numbers are supposed to be encrypted in transit, which should theoretically protect them if someone intercepts the data. The problem, however, is that a PIN must pass through multiple [Hardware Security Modules, HSMs] across multiple bank networks en route to the customer's bank. These HSMs are configured and managed differently, some by contractors not directly related to the bank. At every switching point, the PIN must be decrypted, then re-encrypted with the proper key for the next leg in its journey, which is itself encrypted under a master key that is generally stored in the module or in the module's application programming interface, or API.To be fair, the article title is unnecessarily inflammatory since this doesn't involve cracking the actual PIN, but simply exploiting flaws in the design (no one is cracking crypto in this case). There is no legitimate cause for this type of problem nor a need to decrypt at various points in the network- it's kowtowing to backward compatibility concerns that is causing a problem like this.
"Essentially, the thief tricks the HSM into providing the encryption key," says Sartin. "This is possible due to poor configuration of the HSM or vulnerabilities created from having bloated functions on the device."
Sartin says HSMs need to be able to serve many types of customers in many countries where processing standards may be different from the U.S. As a result, the devices come with enabled functions that aren't needed and can be exploited by an intruder into working to defeat the device's security measures. Once a thief captures and decrypts one PIN block, it becomes trivial to decrypt others on a network.
Friday, April 10, 2009
Thursday, April 9, 2009
get State:/Network/Service/0/DNSd.add ServerAddresses * 192.168.1.1 10.0.0.1set State:/Network/Service/0/DNS
#!/usr/bin/env python# Viscosity DNS Support Script# http://www.viscosityvpn.comimport os, re, sysnameservers = search_domains = os.system("scutil < /usr/local/bin/changeDns.pref")
resolver #1nameserver : 192.168.1.1nameserver : 10.0.0.1order : 200000
resolver #1nameserver : 10.0.0.1order : 200000
Thursday, April 2, 2009
Wednesday, April 1, 2009
Tuesday, March 3, 2009
rule "Close Garage Door"
event : TimeEvent()
garageDoor : GarageDoor(doorOpen == true)
jabber : JabberAlarm()
log.info("Closed garage door by rule on " + new Date());
jabber.sendNotification("Closed garage door by rule on " + new Date());
It keeps me from letting all the riffraff in when I leave the door open at night. Thanks drools!
Wednesday, February 25, 2009
Wednesday, February 18, 2009
Someone in the identity movement should contact Hollywood and tell them to knock off the sci-fi authentication schemes. I'm convinced that is where much of this biometric craze originates. Isn't painful to watch a show where biometrics provide the "strong" security (which actually offer trivial protection), and the next scene has a ciphertext or firewall being cracked in seconds? I'm talking to you, 24.
Sunday, February 15, 2009
Friday, February 6, 2009
Monday, February 2, 2009
Sunday, February 1, 2009
Saturday, January 31, 2009
"Be sure to write down the insane password it generates for you (below), as a weak password would be far worse than a strong password jotted down on a sticky note next to your PC."
Thursday, January 29, 2009
Monday, January 26, 2009
As is the case with many companies that maintain large databases of information, Monster is the target of illegal attempts to access and extract information from its database.
It is important to know the company continually monitors for any illicit use of information in our database, and so far, we have not detected the misuse of this information.
If the information has been accessed (and probably copied), how do they intend to detect/prevent the misuse of information? Maybe they should enter the DRM space if they've got the solution.