$a = passwO_rd1; $b = ($a striped down to lower case); $c = ($b's metaphone); $d = md5(md5($a.'salt1'.b).$c.'salt2'); $e = md5(md5($c.'salt3').$c.'salt4'); Store $d as encrypted password then store $e as a string to check against. have $e saved in a separate communal database so to brute force $e and then guess the missing characters and the right user it would be. ([missing characters]^[character set])^([password lengh] ^ [users])^2 or something along those lines
I read the paper and it's very interesting. I always wander how would I know if my DB is compromised and this provides a solution, i don't know and I am not capable to tell if this is a great solution or not but it makes sense.
As a note to the paper for the 2.1. Honeychecker; It's not that efficient to have a second system that stores what the correct password is, it's just a waste of resources. A simple and more robust solution could be to have a checksum from a field, let's say the username, that generate a number from 1 to 5. That way you can tell which password is the correct one. The attacher must have access to the code to know the checksum formula and how that applies to the password list. I guess this is much better than the suggested solution.
Just take a random string, encrypt it with the password and save both plaintext and encrypted version in localStorage, stuff a username in one or another if needed. This will allow you to check if the username/password combo is valid.
You could take the first N characters of the password and store that as a secure hash. That would catch people choosing password1, password2, etc (but wouldn't help much with 1password, 2password...)
The safe way to do this is to check a password against a list of common passwords, as Jeff Atwood suggests [0] rather than against your other passwords. As other replies point out, you shouldn’t be able to compare your passwords’ plaintext to each other like you’re proposing[1].
[1]: I suppose you could salt and hash the user’s password against every other user’s password and their salt, but if you chose an appropriate password hash function and parameters, that would take infeasibly long.
Edit: I missed that you essentially suggested this already. Sorry about that. However, I think the way Atwood explains it is useful.
ect, then check the submitted password by testing it against these hashes by removing characters in the same fashion.
Just as an early idea.
I think it's a good idea, what if you could encourage users to use stronger passwords by telling them that "the system will forgive near misses, so don't be afraid"?
If they're using pbkdf2, scrypt, bcrypt, etc., there's a much better option than attempting to brute force a database of salted passwords.
You could check a lot (depending on language speed) of common passwords whenever a password is chosen, or during login, when you still have the password in cleartext. When it passes the checks, set a flag for that user so that the check doesn't have to be repeated.
If it takes to long to do during login, have a counter that keeps track of where in a list of passwords the checker is at, and do N more each login.
I use my own script to generate passwords. I don't store anything beyond a salt. The password is just a hash of the website name, the salt and a master password. Then I just copypaste the result. Simple is best.
I've been using a system like this for a while. It doesn't need to be as complex as this article suggests.
Something like this would work fine:
Get the domain name, take the first 3 letters, reverse it, replace each character with the character that sits to the right of it on a keyboard. Append (or prepend) this to an already secure, remembered, password.
The only way a person can know which part of the password is variable is if they have access to two passwords generated by this system, from different sites. Highly improbable. Moreover, even if they do figure out which part does change, they have to try to reverse the algorithm.
I tinkered once with hash of a user's passphrase, salted, and then using 4 digits from the middle of the resulting hash as a username. I then used a different 4 digits as a cookie token so they only had to enter it once per sesssion. It's not terribly secure, it's not collision-proof, etc, but you may find some use from the basic principle - it's quick and easy and was useful on the scale I needed it for :)
Edit: Point of note: The same people who wouldn't type 16 characters of username and password would happily type 30 or 40 character passphrases... There's some novelty to it, apparently :)
The problem with that approach is that once someone figures out 1 of your passwords "PclarkUnsecureWebsite123$%^", it becomes easy for them to guess "PclarkGmail123$%^".
Made this the other night. It hashes the password before it sends it off to the server, to check to see if it exists in any password lists. Made it for fun, I will open source it too.
I just discovered an even more obvious and easy to automate way. Pick random words, like "newyork", and MD5 them. Then search for them on Google (or elsewhere), adding a whitespace and then "@gmail.com" or "@hotmail.com" or whatever. It'll show a list of accounts who have used "newyork" as their password with a web-service once, and possibly their e-mail account as well.
as a programmer, all logic and simple. but it still is really scary.
A really awesome and simple solution would be to ask users to use non obvious sentences as their password. Even better would be to ask them to use a non grammatical sentence with deliberate phonetic spelling variations.
Although that would be ineffective against a sophisticated brute force attack to crack the encryption itself over a period of days, but it would be an awesome stopgap.
This is great, but if you use a password manager, it's very difficult to determine which, if any, of your accounts would be compromised. For myself, this would just be doing a dump and looping a few greps. But for family and friends, does anyone have any ideas for a less technical audience?
reply