Want to Block Common Passwords? Sorry, That is Patented
xato.net
xato.net
This would certainly stops patent trolls, and avoid making people suspicious when you claim "protective patents" as you describe.
a) it's about things that should have been actually used, where a patent is about concepts
b) scope of the idea is not clearly defined and so could be argued with, when a real patent definition for general public use would prohibit that.
And that's excatly the point for IBM to issue protective patents, I think.
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.
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.
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.
They don't have a user => password relation, but having a list of passwords to go through will make any bruteforce attack extremely fast.
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.
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.
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?
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 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).
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.
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.
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.
And he was enlightened...
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.
foreknowledge of patent infringement can triple damage liability right?
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.
Edit: Well, who knows? Try it and see. Even in the worst case, you can almost certainly cut a deal.
Edit: A quick Google found this, seems I would be OK. http://answers.onstartups.com/questions/21560/what-happens-w...
That's the problem. The patent system puts all the risk on inventors, none on IP holders.
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.
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.
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.
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.