There will be people who say that it would all be fine if they just used bcrypt, but the fundamental problem is that if you don't use different passwords on every site, you're hugely at risk.
Consider a situation where you've given your "trusted" password to a site that you know does all the right hashing with password storage. Your super password is 20 characters of alphanums with specials and you're feeling pretty smug. You now hear that the site was hacked, but you're not worried as all they can get is the hash and let them just try brute-force, right?
Wrong. They hacked the site. They changed the login form and grabbed your password in plaintext. A hack means that they compromise part of the infrastructure. At this time it's sufficient to just grab database data. Changing presented HTML is possibly a little harder as it needs to stay up for longer, but if someone has access to the database, they probably have access to a whole lot more. This is why lastpass.com is less secure than storing your password database yourself.
TL;DR: make your passwords different.
But yeah, at the end of the day, someone who spends a lot of time making cryptographically secure passwords and rotates them every six months is probably less secure on the balance than someone who uses 4-digit pins they rotate every three months.
If lists of usernames/emails are available elsewhere for users of the site - a NastyPerson can reasonably quickly lock your entire user base out of the system (either deliberately, or by a poorly coded password attacking bot).
If you have per-IP lockouts then you're still open to bot-nets and the problem doesn't get much better.
What seems to work best is to slow logins down rather than lock them out completely. Still lets users in, but slows down bulk attacks enough so that the risk is low.
And having nice metrics / reporting tools so that you can spot attacks as they're happening and make appropriate case-by-case responses.
Forcing a CAPTCHA for a new IP address or when a "you-have-logged-on-from-this-browser-before" cookie added to a lock-out would definitely be an improvement.
1) Username is not known. No reason the attacker would know this short of a leak / social profile with identical username. In this case, submitting random usernames and getting a hit should trigger a lockout and corresponding alert.
2) Username is known through system compromise. In this case, the account should be locked out and a new password generated just in case.
So I don't really see causing a deliberate account lockout as a primary attack vector other than trying to exploit weaknesses in password reset processes across multiple sites (like what happened to Dan Harmon).
Therefore, I would say that having a lockout mechanism is better than not having one.
You're assuming that the lockout is aimed at an individual. In my experience it's aimed at the site. They're trying to lock out N% of users. In which case going for common names, email addresses, etc. will get you a surprisingly large chunk of the user base.
And that's ignoring the many sites where usernames are public, or easily accessible by a "normal" user that can be used to scrape them for the DOS/password bot.
Therefore, I would say that having a lockout mechanism is better than not having one.
Since I've seen DOS attacks that use them - I'd tend to disagree :-)
Unless you're in an environment that makes them effective.
For example my bank uses a lockout - but it has a private customer number that's not visible to others, along with a separate password and a 8 digit PIN (of which it only asks for three random digits). It's only when two of the three bits of information are correct that the lockout count starts - making bulk lockouts for the site pretty much impossible. So there it's an effective tool to prevent password cracking.
Users should have a handful of passwords, in the old security-level style; everyday sites use a short simple password, email a level up, banking a level up again.
But the passwords should not be entered directly into sites. Instead, they should be hashed by a browser feature / plugin, roughly equivalent to bcrypt(password + user-specific-salt + site DNS name). The output of this process is what gets provided to sites. Not all sites will accept the full entropy of bcrypt or similar, so there needs to be a central registry tracking acceptable mappings from the output of bcrypt to the input of a site's password. There's also an issue around sites that share accounts across different top-level DNS names - Amazon in particular - that can also be handled by the same central registry technique.
The only thing you need to worry about is your browser getting completely owned, so that the memory space of its extension mechanism is accessed by remote websites. But if the attacker has that level of control, it's not unreasonable to think he has control over a third party password manager too.
What it doesn't do well is revocation and renewal of a password. It also has a single point of failure - if someone somehow gets access to your underlying password, and knows the mechanism and salt, they can open a whole lot of boxes. This, of course, is why I'm a crackpot: I can live with that.
But you still need to realize that this won't last forever. You can crack an application's hashing algo (and know what hash or field they're using for the salt) because 50% of its users picked crappy passwords. Then if you're really dedicated you can work on the double hashed passwords, knowing that most people use the domain as the salt for browser-side hashing... Also a pre-hashed password has to be pretty easy to spot in a list once you've cracked the server-hash.
You might want to look at it again.
All of the choices are hash functions designed to be fast (like SHA-256, the default), which you do not want for password derivation because being fast to compute means easy to brute-force. You can test billions of digests per second with a PC graphics card.
let's me specify a different salt (domain of the site is the default)
Then every user shares the same salt for a given site, which largely defeats the purpose of salting (to prevent rainbow tables).
1. Install and use the Passwordmaker Pro extension. https://chrome.google.com/webstore/detail/ocjkdaaapapjpmipmh...
2. Change the default password length to say 40 characters.
3. Add a modifier like bOoo7&jd8$02jf
4. Change whatever other defaults you want.
5. Use a master password that's at least 10 characters long.
BTW it would be easy enough to fork this extension and provide a little more security if you wanted.
Do the math. 676 million should have taken less than a tenth of a second. Unless some rather major details are missing...
> An updated version of LAN Manager known as NTLM was introduced with Windows NT 3.1. It lowered the susceptibility of Windows passwords to rainbow table attacks, but didn't eliminate the risk. To this day, the authentication system still doesn't apply cryptographic "salt" to passwords to render such attacks infeasible.
Is this true? Do WinNT-derived systems _still_ not use password salting? If that is the case, my opinion of Windows's security just dropped quite a bit. I know security can exist without salting, and I've not done any in-depth Windows development, but from experience w/backend dev and Linux dev it seems like it'd be pretty cheap to add . . .
The problem wasn't the difficulty of adding a better hash algorithm. The lousy hash was kept around to maintain compatibility with network clients that didn't support the new algorithms.
* (what you have, what you are, what you know)
As far as that goes, Google's 2-factor auth mitigates this a bit, with its "keep this auth instance valid for X days" option. (They also have a new "permanently auth this computer by adding it to a trusted list" option, which IMO defeats the point.)
What is is, I don't know. I just know that it's not "passwords".
Especially when there are still sites that limit you to like 8 characters out of a highly restricted set. Usually of course these are banks.
The best I've been able to come up with is bcrypting the md5's. But unfortunately, while bcrypt^-1(ALL STRINGS) is hard to compute, it's not clear that bcrypt^-1(range(md5)) is. I see no compelling reason why it wouldn't be, but I don't know enough about the subject to offer a strong claim.
Can any experts offer advice on this?
(I'd also replace the `bcrypt . md5` password with a regular bcrypt one after the user authenticates.)
If you have a large number of inactive users, this might not be as effective (you'll still be left with lots of MD5 hashes in the event of a dump) but for other sites it can be quite useful.
You can also use the same strategy to increase the work rate of your bcrypt hashes in the future.
Someone asked a question similar to yours a while ago. Maybe the answers may be of help: http://news.ycombinator.com/item?id=4076257.
I guess you could run bcrypt on all your database's md5 hashes and do something like:
if entered_password.md5.bcrypt == stored_password:
stored_password = entered_password.bcrypt
Anyway, if there's any input set X for which bcrypt(X) can be inverted more efficiently than brute force, then you could say that bcrypt is flawed. If that set is the random-looking hashes of user passwords, instead of a carefully constructed one designed to attack bcrypt, then you can safely say bcrypt is catastrophically broken.
Here is one:
[ (bcrypt x salt) | x <- dictionary, salt <- all_bcrypt_salts ]
My concern is that artificially constraining the input set to range(md5) might similarly make brute forcing (or other attacks) easier.
Alter authentication so that it uses bcrypt column if populated.
Alter registration/password changes so that it populates bcrypt by default.
As old users log in (and you therefore have access to their plain text password and know that it's valid) populate the bcrypt with the correct hash.
After a period of N weeks when you've basically migrated all of your active users, do a forced password reset on the rest.
Kill the MD5 column.
The question is what to do to protect passwords starting today?
bcrypting the md5s sounds like a good approach.
If you can, also add a user-specific salt (username is the obvious choice).
In theory cracking bcrypt+md5 is easier than plain bcrypt, because users could have passwords with greater than 128 bits of entropy. However, the vast majority of users won't, and generating a 128-bit rainbow table isn't practical.
I don't think this is possible, since bcrypt has a built in salt.
Does the fact that you bcrypt and md5 undo this salt? I.e., is bcrypt(md5(password), salt1) == bcrypt(md5(password), salt2)?
This guy is realistic. And he is right. I started revoking access for my google account from a lot of websites.
BTW I've seen a blog post that a guy was able to access his stackoverflow account by getting the session cookies (which was very easy, the parameter names, etc) just by using a cookie chrome extension.
This guy is totally right.
"If you think every single website
you have an account on is secure and has never been hacked,
you're a much more optimistic person than I am."
(It would also help attackers, of course - they could instantly lock owners out of whole heaps of accounts once they got a password that got reused. On balance, though, I think the benefits would be positive, since a motivated hacker can already lock people out of high-value accounts, and the drudgery factor of changing passwords regularly is very high.)
It would be totally awesome if Apple acquihired 1PW or LastPass or somesuch, and set things up so that it's always right three, helpfully offering a new super-entropic password whenever you're joining a new site.
I'm using my friend's laptop; I don't have my private key with me. Now what?
I'm travelling and forgot to bring my private key with me. Now what?
(Similar questions apply to password managers as well, but I'm curious as to what the problems/solutions are for PKI.)
But I sincerely hope a requirement for me to use the internet doesn't demand we have a private server instance or a smartphone of any variety (my Nokia candy bar variant serves me just fine).
I can think of many problems we'd need to account for (lack of internet, dead/lost phone, corruption, older folks, etc).
1. Shared secret/Password - He tells me something during registration and then I use that information to verify if he's saying the same thing when he want access the site.
2. PKI - Describes itself.
3. Something he claimed to have during sign-up, so let me check if he has it now.
The problem is, every system is going to have a point of failure/point of absolute control. This is because, you want someone to be able to reset their password/public key/auth token if they forget/misplace/get stolen. Sure, things would be a lot easier if you left the liability on the user, by explicitly stating that if Acts of God (legal term) happen to him, you are not liable. But in this day and age where I see every service tending towards dummifying and hand-holding, I don't see this approach being popular at all.
In the above approach, by pushing all liability onto the user, you tell him that HE and ONLY HE is responsible towards the safe storage of his credential. It's not like in real-life, people can't come up with a gun pointed at you and tell you to give up your auth token, assuming they MitM'ed your password.
My main objection was calling for using a device that is expensive, requires special/additional phone plans, and doesn't _really_ solve the problem (especially for most of the global population). I have a rather diverse set of friends by age, income and technical experience - and smartphones aren't the majority.
7 reasons why you should add Rublon to your website
I'm the inventor of this technology. Sorry if this looks like advertising, but I think that the problem with passwords nowadays is huge nowadays and has to be solved. BTW: We're releasing a new Android app in a few hours.
3-5 tries with a half hour lockout with an email alert seems like a good solution to me...
Unfortunately, you can't create new records from the mobile device with Keepass (at least, with the app I'm using; there are others). My technique is to not create high-value accounts from my mobile and for low-value accounts, I'm OK with just using a semi-secure, temporary password that I update when I'm back in front of the desktop.
Perhaps pwSafe is the app you need? Works beautifully on iOS and syncs with Dropbox and/or iCloud too!
Works just fine with version 1.x files
Accounts could still be cherry picked but it would stop blanket brute forces. This is why BCrypt is good.