Re: IBM patents,
IBM has an interesting, and quite unique strategy regarding IP. About 20-25% of IBM patents are software patents, and IBM uses this patent portfolio to protect open source projects, especially Linux (http://www.linuxplanet.com/linuxplanet/opinions/7034/1). Also, IBM historically abandons a large portion of its issued patents (http://www.patentlyo.com/patent/2012/03/ibms-patent-abandonm...), and the abandoned patents become prior art, protecting everybody.
That's a valid point. I still don't understand why there is no (afaik) "general public patent" mechanism of some kind : a procedure to make someone claim a patent on behalf of general public.
This would certainly stops patent trolls, and avoid making people suspicious when you claim "protective patents" as you describe.
What you're describing is known as "prior art": simply publish your idea anywhere public, and it automatically becomes invalid for patenting. You don't even need to implement anything.
This is how it should work, but unfortunately it seems that the patent examination process does not work that well: Often trivial patents or patents with prior art are granted anyway, and one then has to risk going to court to invalidate the patent, which is highly undesirable for e.g. a private person developing free software in their spare time. Hopefully, in the US this will improve with the new patent reform.
Personally I believe that we should simply abolish software patents: Innovation in the software world seems to thrive without a patent process too, and in fact the patent process seems to be a major hurdle for small players to enter an existing market here.
Is there a well know central place for this? I once considered starting a web site for this sole purpose - to let people publish their ideas to establish prior art - but I don't have time to manage yet another web.
As I understand it, patents apply to applied inventions, not to concepts. In other words, to patent an idea, you need a working model. A patent is a time-limited legal monopoly on making the application, granted in exchange for disclosure of what the application does and how it works.
I've seen numerous patents for concepts with no working models and not just software patents. They do explain how such a device would work and many do seem reasonable, but they often will not have a built and working example.
Prior art in itself does not provide a defensive punch. But, if a company X decides to go about suing everybody using Linux and databases, because it competes with X's business, a large patent portfolio will act as a big stick for defense against X, and other possible Xs considering the same tactic.
Not to be melodramatic, but as someone still in a day job this whole patent mess seriously does discourage me from taking the leap and risking everything to try to invent something meaningful only to get hit with a patent troll lawsuit just as we start to find our feet.
Sure, he would be "lucky" to be in a position of potentially losing his business and/or idea in the course of defending it. There's potentially a huge cost even if he were to win.
Don't worry. The patent trolls only come after you earned a lot of money (who wants to sue a poor company) at which point you should be able to throw enough money at some lobbyist in dc to make the issue go away.
The problem with blocking common passwords is that quite often you just end up creating a new set of common passwords.
I had to set up a management system a while back, and given the sensitivity of the data, it seemed prudent to block passwords such as "password" and "123456". The result? The most common password was "drowssap", even after an email explaining why they needed to use strong passwords.
I could have gone back and added something for permutations of common passwords, extended my exclusion list or any number of other solutions, but it seems like every time you find a way to stop a user being a security problem, they find another way.
I remember a paper, from Microsoft I think, where the proposed method was to keep a list of all passwords and prevent any password to be used more than X times. This way no password becomes common. But it would likely be frustrating for users who try to find a password (like trying to find a username on Hotmail: everything is taken!).
You could at least bcrypt them all with the same salt, however, it's a long step backwards from individual salting. Also, then you can't check for "[common base password][phone number]" or some variation that's exactly as dangerous as just using a common password - if you kept a plaintext list, you could do substring searches.
The more important lesson here is probably that your users insisting on using crappy passwords isn't really a problem for technology to solve. If you users aren't in the mindset of feeling an obligation towards protecting the data, there are much bigger holes in the network than password complexity enforcement.
I think that the main problem is always going to be the end users. I'd like to say that fingerprints or iris scans would solve the issue, but they have their own problems (e.g. having a backup password in case prints or scans aren't recognised).
I agree that it really should be the user's attitude that needs to change, but there will always be that one person even if the other 99% of people get things right - so I think that at least trying to build a system to compensate for this is just as worthwhile as educating users.
I quite like the idea from XKCD [http://xkcd.com/936/] of using words instead of letters (but also have a few problems with it), perhaps rather than having passwords, we should have pass sentences that also have requirements (8 words of more, at least 2 punctuation marks, for example) or are generated for the user (could be nonsense sentences or contain misspelt words).
Is it me or is individual salting rather redundant.
I can see why using one salt forevermore is rubbish but if I salt a different user with a different lt each time, but I need to keep that salt in plaintext next to the hash. Making the whole salting thing a bit redundant if I get a linked in style loss
I certainly see a benefit in padding out user passwords to say 128 bits each time, combined with crypt it will slow down any mass brute force /rainbow attack.
Pre-edit edit: I just answered my own question did I not.
If I understand your point correctly, you're asking how critical it is to always give different/random salts to each password?
Even if you know that hash('password', 'salt1') hashes to a a user's hash, you'd need to recompute hash('password', 'salt2') to check if it's the hash for someone else. It slows them down by increasing the amount of work. If they had the same salt it would be the same hash for multiple users.
Sort of - I had always thought of a salt as another password - something to keep secret so that if the dbase of hashes was lost, there was an "unknown" component that would take an age of searching to find.
This logic is clearly flawed - if they have the dbase they presumably have everything.
So I now understand more clearly - salts are there to
1. pad out the plaintext to increase time to compute
2. convert plaintext from commnly used words (pass1) to
unique plaintext, reducing the ease of cracking multiple
passwords.
In short, salts help slow down the attacker when he has all your hashes. Just like bcrypt et al.
1. Set up something like a bloom filter, tuned to give lots of false positives.
2. Fill the list with the 100,000 most common passwords.
3. Every time someone proposes a password, see if it hits. If so, goto 3. If not, let them use the password and insert it into the list.
I think you probably want to scrypt[1] the passwords first. If someone gets the list, they can rule out that no one has certain passwords. I'm not sure how much of a failure that is.
[1] EDIT: I mean scrypt without a hash, which might be nonsense. Or the same hash for everyone. Yes, this sucks for storing individual passwords, but it helps you build the "master list." I'm not sure there is a way around this paradox if you want to have a master list, but the bloom filter will throw a lot of noise into the mix.
I would expect that you'd just compare the hash, effectively performing half of the log in process to check if the password's okay. I imagine it'd be pretty costly in terms of performance if every time you wanted to create a new user you had to hash the password, then check against a (potentially huge) table to see if that password had been used >X times.
Hopefully I'm being short-sighted or missing something that'd mean this could be done simply and quickly, because in theory it sounds like quite a good idea.
If you're using per-user salting (and you should be) then you have to do n hash calculations, not just one calculation and n comparisons.
Might be feasible for a small number of users on an internal app, but unlikely to work on a big or public site.
I'd also be worried about information leakage. If you tell me that I can't use my password then I now know that it's used by someone else. If I work out who that is (which could be quite easy) then I can impersonate them.
Even more performance-intensive than I thought - possibly why it's not been implemented.
Assuming you know that a given password can be used 10 times and there's a database of 100,000 users in your scenario above, how would you work out who that is?
IANAL, but foreknowledge of patent infringement can triple damage liability right? So is just having the headline of this story on the front page of HN enough to cause problems for the entire HN community?
This comment is a little problematic. Despite the INAL qualifier, you seem to be offering legal advice or strategy. Secondly the logic is stretched,... viz: "enough to cause problems for the [entire] HN community?" Clearly for all of the non-infringing HN readers, and those for whom Ignorance is [not] bliss, here might be some interest in it. That being said, the point is a fair issue to raise. But a better note might be: check with counsel.
That's my point. The post is cobbling together "foreknowledge" "infringement" "liability" into a statement with a rhetortical, "right?" tacked on. It not obviously a genuine question, though (by definition). viz:
foreknowledge of patent infringement can triple damage liability right?
These frivolous software patents are actually a blessing in disguise and will ultimately be their own undoing. As more and more "patents" are filed and trolls do their best to sue people into compensation, the media song & dance will get stronger and policy makers will sit up and take note. Then it's just a matter of time until blanket reforms are made.
Blanket reforms will never happen in real world, because we're talking about huge quantities of money involved - a blanket reform the way, say, "many people would like it", would cause a sudden big loss to loss to big & powerful entities.
Absolutely. That's why we're still firing union workers and working child laborers thirteen hours a day. Once enough money was involved, things just couldn't change and therefore patents never will either. Not in the real world.
If I'm based outside of the US and my servers are outside of the US, these software patents would not affect me and I could implement them without risk?
I understand the site could be blocked from US browsing but that would seem extreme, especially if I registered a country TLD like .co.uk.
In plain English, I don't these patents apply to my country (UK) and are not enforceable here. But I could be wrong.
Thinking about it - why big companies don't move then? To avoid software patent cases? I mean they can still have skilled workers working in Silicon Valley, can't they? But the company is registered somewhere where they can't sue them. Or what am I missing here?
I would assume having an office in the country means a presence which means they follow the law. Plus just doing any kind of business inside the country, including contractors, makes them subject to local law.
I would not recommend taking advice on complicated matters of international intellectual property law from a Q&A site on the Internet. Go talk to a lawyer.
How could there not be prior art for this? I know that patents are more specific than the title of the patent, but if the patent isn't general enough to cover prior cases of blocking common passwords, then the patent doesn't even protect anything for the patent's authors. If it is general, then it is surely an invalid patent, even by US patent office standards. Very confusing.
I get why you'd want to check for weak or common passwords, but why not just require passwords to contain numbers/special characters? It may be a pain in the butt, but it takes users' lack of care for security out of the equation.
time to reform the patent review process. there is so much energy wasted fighting patent trolls. furthermore, this produces nothing, it just leaches on the wealth creation efforts of others.
For serious systems-based access, it's been key-based auth for most of the past decade. Even embedded systems (switches, routers, load balancers, DD-WRT-based WiFi routers) offer SSH key-based auth.
Key management presents its own set of problems, but most are vastly preferably to using poorly-selected passwords on a myriad of sites.
I'm always tempted to switch to key-based auth myself, but I travel a lot and the thought of me losing my private key and thus being permanently unable to decrypt my files/log in to my servers scares me to death.
That's the fatal flaw in the key-based system: while the chances are slim, if you lose the key or it gets stolen (stolen laptop?), the consequences far outweigh the benefits. I'd rather just remembering a complex password for personal encryption/ssh, use a simple throwaway password for general web app use, and not have to worry about losing a key.
Key reissue is really just a slightly modified case of password reset.
In my case, for work systems, I'd either fall back on a system password (yes, they exist and can be used, but rarely are, and are secured), or make an out-of-band request to a co-worker.
In a larger context, you'd want some way of demonstrating that you are who you claim to be (not a trivial problem, but essentially the same one that exists in the password scenario). A one-time time-limited token would be distributed, notifications sent to your contact address(es), and once on the system you'd generate/provide a fresh key.
Keys should, of course be protected. With passwords. As I noted elsewhere, you're not going to eliminate the use of passwords, but you can greatly reduce the threat surface and present problem of huge numbers of readily attacked, weakly secured accounts, many with reused passwords which can be found in existing password corpora.
You can simply back up your key (encrypted with a password!) on a cheap USB stick or CD you keep somewhere that you consider safe enough for your purposes.
It could be a one-time issue used only to set up a secret. I think the fatality in question is the user-selected password, which is proving useless at scale.
Passwords not shared across multiple systems, and used rarely, on physically secured and/or proximate systems. The threat exposure is vastly reduced.
The main problems with passwords today are 1) rampant reuse and 2) very effective cracking tools based on known password corpuses. Even a small corpus of a few hundred of the most common passwords will generally access some account on a given system.
