We're talking about letting a machine/program know you are really you. Right now a lot people concerned with this topic also carry around advanced computers (smartphones) with HD camera's, GPS, Compas and Near Field or Bluetooth communication capabilities. Surely it would be possible to use something else than keyboard-input to let a machine know you are really you?
A login by 180° close up picture of your face combined with location and IMEI or something? Combining bio data with location and machine or what not... Any ideas?
Many (most?) web services and software only require the former, not the later. They don't need to know that you're Joe Bloggs, only that you're the unidentified person that created the account and are the one entitled to use it.
This is a more and more important distinction as privacy issues grow.
No password needed at all - your email provider verifies your identity to your browser, and then your browser uses the key generated from that to sign you in.
You can also self-host and choose any authentication you want, however specific to you.
Also, this isn't directly relevant to what the GP said, but using a standardized, decentralized way to authenticate is a huge win. It effectively turns all sites into requiring arbitrarily strong authentication (at the very least, everything suddenly supports two-factor auth when it supports Persona), but you still don't have to trust a third party with your authentication (you can run it on your home computer).
And once that happens, you can't change a password that is your face.
bcrypt $2a$ 3788 c/s 1583 c/s 3861 c/s 626 c/s
I hope we see a much stronger push to two-factor auth soon. Even if it's imperfect (e.g. SMS messages) it's still a huge extra hurdle for the typical cracker.
That means, if your db is compromised, it's pretty much game over for your users (who will invariably reuse them elsewhere) if you used simple hashes - another key takeaway. Bcrypt (or better yet, scrypt) is still the better option for this very reason.
Edit: To clarify, it doesn't matter that you limit logins, lockout users after failed login attempts etc... (although, those are good measures to start) The password hashing scheme must withstand bruteforce cracking of this nature to a feasible degree regardless of what limiting protocols you have in place. Just in case...
every webmaster/admin cracks their collection of hashes against common wordlists, and if any given password appears too often (or at all, against a weak wordlist), user is forced to change it.
"But complex passwords are too difficult to remember"
"Must I have a different one of those for every service?!"
Nope. ebay, twitter,facebook:
also, as has been pointed out - bcrypt.
are there any hash ciphers that allow offline cost stretching yet?
The example was over simplified, but i guarantee you if you got one of my passwords you wouldn't work out where the per-system bit is.
These days I just use a password manager with a big phrase for the master. I couldn't tell you what any of my other passwords are.
So the crackers are optimized for single-block messages (passwords), since making the length generic would slow things down. I guess they've added support for that now.
>>> from math import log
>>> log( 62 * * 55 ) / log( 2 )
55 character uniformly cryptographically chosen alphanum passwords contain over 327 bits of entropy. If an attacker were using an irreversible but thermodynamically ideal computer floating in space passively cooled to the temperature of cosmic background radiation... the amount of waste heat from her computer would be enough to boil away Earth's oceans. I'm too lazy to look up Bruce Schneier's calculation for counting to 2 * * 256, but counting to 2 * * 327 may very well require more energy than our Sun will output between now and when it goes cold.
Now, all of the basic qbit operations are reversible, so the above theoretical lower bound on waste heat doesn't apply to a quantum computer. However, if the hash algorithm doesn't have any weaknesses and has at least 326 bits of state in an optimal implementation, it will still take an attacker 2 * * 163 hash operations on a quantum computer, so at least 2 * * 163 times the clock cycle of the quantum computer.
Or... even given some rather weak assumptions about SHA-1, if your bank and FunnyCatPitcures.com both use salted SHA-1, and the stolen password hash is 160 bits, but the password itself is 327 bits, an ideal attacker is going to find your password along with about 2 * * 167 false correct answers. As long as your bank uses a different salt for your account than FunnyCatPictures.com did, then having your password hash from FunnyCatPictures.com doesn't help an attacker.
Basically, as long as your password has at least twice as many bits of entropy as the stolen salted hash, the number of false positives (hash collisions) from cracking the hash is more than the expected number of random guesses needed to get a false positive (hash collision) at your bank, so the attacker is better off just throwing random guesses at the bank.
Horse.. in a box riding a fish!
For comparison, the first password you provided (16 random alphanumeric characters) has 95 bits of entropy.
On a related note, has anyone analyzed the entropy of markov chain generated passphrases?
Summary: Highly entropic Markov-generated phrases are long and hard to remember.
echo $( shuf -n 4 /usr/local/share/4000-common-words )
4000^4 gives 256000000000000 giving 3.3 bits of entropy per decimal digit it comes to 50 bits of entropy. Not too shabby but not that secure either. Your PCs rng may play you dirty tricks.
And of course there are all kind of legacy systems with password limitations to 32 or 16 character, but above 8 etc etc which would further reduce the pool.
Of course you could try your own password deriving mechanism. Take the first 16 characters of bcrypt(username,site domain) it will produce awesome passwords for any site that you will have easy time producing when needed. Until the hackers begin to suspect what you use if it becomes widespread.
(Disclaimer - not a cryptographer or security expert or particularly competent in anything)
Hey, that's the very definition of security through obscurity ;)
Here's a thought experiment I use when estimating security of similar password schemes: imagine you asked someone to come up with 1000 different mechanisms of generating passwords based on username and domain. Is your scheme is likely to be among them? If yes, this means it provides less than 10 bits of security.
Please don't discourage good practices. Four random words is a lot better than "password123", though it would still take 1.5 day to crack it if it were stored as an MD5 hash. Six words would take 65 years at 1ghash/sec, which is pretty damn good, and better than a 12-char random password. 5 words would take 16 years, which seems like a pretty good compromise.
EDIT: Although, I don't like straight-up Shannon entropy as a measure of password strength.
Any password derivation scheme works brilliantly until you are the only one using it. The moment it becomes widespread and people begin to target it - it goes anywhere from significantly weaker to trivial to crack.
Maybe that's no longer secure enough; I don't know how fast password crackers are now. So use "shuf -n 5" instead.
At all? You still need a password for your keyfile. And probably you need an OS login before that.
However, if you're going to use a brute-force attack on a website the way to do it is to try a common password on every username you can think of, not every password on a single username. And a way to prevent them from simply blocking your IP address, like using a botnet.
> This isn't an online attack. Hashcat and variants work by attacking the password hashes after they've been leaked/stolen somehow. Not by attempting billions of logins per second over the Internet (if any server allowed that... someone needs to change careers).