Jeff on mayonnaise
-
You guys and your silly weird numbers. At least use something nice and round like 256 ...
-
256 is square, not round.
-
I scanned the entire Encyclopedia Americana to high-resolution bitmaps and use that
You ignorant, if you had used a camcorder you could search through it now!
Filed Under: SpectralSwamp on passwords
-
A random-random reverse slow-mo encyclopedia video. That's quite possibly the most boring idea ever to come from TDWTF.
-
I see your point. Just one question though: if passwords can be longer than what your hash algorithm takes, what method would you use to select the substring (and repeat the same procedure when checking the password)?
Because if you just take the first n characters from it, or m characters from the middle, how does that mitigate the problem? I mean, yes, it's a bit harder to figure it out, but it looks like to me like an unnecessary step, provided you use random per-password salt of course.
I don't understand what you're getting at; that's not how (most/modern) hash functions work. They take input of any length, and always change value if any bit in the input changes. For example, this is a hash function:
unsigned hash(char * s) { unsigned h = 0; while( *s ) { h = h * 31 + *s; s++; } return h; }If any byte in the input changes value, this propagates through the hash and the final hash changes, no matter the length of the input.
NOTE: this is not a cryptographic hash, but it's a nice hash to base your hash table on.
-
Let's just say that that's why I never wrote my own and let other, smarter people do that shit and just use a library
I mean, if I took the time to learn all this I'd probably get it just fine. I just never had the time / inclination to poke around it because, frankly, I thought it would be a boring read.
Maybe I should read some of that stuff one of these days, though.
-
I didn't use the password entry box, I used curl.
time curl blah POST http://try.discourse.org/login blah blah login=garbage&password=`python -c 'print "a" * 20000'` & time curl blah POST http://try.discourse.org/login blah blah login=garbage&password=`python -c 'print "a" * 20000'` & time curl blah POST http://try.discourse.org/login blah blah login=garbage&password=`python -c 'print "a" * 20000'` &(repeat UNICORN_WORKERS * 2 times)
Passwords are now limited to 200 characters. I used 20K to test, but that was not the limit - there was no limit.
-
I'm not saying I think you, personally, would mess up your security
I'm not so prideful as to never admit my lack of knowledge.
But what I'm saying is that if you use passwords longer than the entropy, you make it that much harder to determine the methodology of the hash.
And therefore you protect everyone.
But if someone manages to brute force your account, having a password longer than the entropy only overlaps onto existing hashes.
-
I'm not so prideful as to never admit my lack of knowledge.
But what I'm saying is that if you use passwords longer than the entropy, you make it that much harder to determine the methodology of the hash.
And therefore you protect everyone.
But if someone manages to brute force your account, having a password longer than the entropy only overlaps onto existing hashes.
You're absolutely correct. The number of possible passwords that produce the hash that will unlock the account goes from 1 to whatever number of hash overflows you allow in the byte space.
The response to this concern is that X/(2Y) is close to 1/(2Y) which is close to 0 as long as Y >> X. In other words chance of a collision on any given hash goes up an incredibly small amount, but the number of potential passwords the attacker is required to check goes up exponentially as long as the number of bytes in your hash is significantly larger than the number of hash overflows. And the result is that, they will have a 1 in X chance of guessing the password because there are X possible solutions. The hash has becomes non-deterministic of the original content used to produce it.
Or there's really not much of a difference between 2 out of one billion odds and 1 out of a billion odds.
-
This discussion reminds me of a stupid thing I did once.
Built an automagic system for handling the input/output of PGP encrypted files, including the generation of keys. Since the keys were to be used solely by the automagic system and support personnel for troubleshooting purposes, I figured I'd just have it generate properly ridiculous passwords.
So I settled on 1000 characters.
Bouncy Castle handled it just fine, so I called it job done.
Until the first 'customer is doing something stupid, can't figure out what. Need to try running the file through gpg' situation came up.
Turns out that GPG, at least on Windows, trims password input somewhere short of 1000 characters. Ended up having to revoke that key pair and start fresh.
-
GitHub - BenLubar/battcrypt: Package battcrypt implements Steven Thomas's "Blowfish All The Things" cryptographic hash function.
Package battcrypt implements Steven Thomas's "Blowfish All The Things" cryptographic hash function. - BenLubar/battcrypt
It works with passwords up to 340282366920938463463374607431768211391 bytes long.
Yes, that is the actual number.
-
What should password length be limited to?
Whatever bcrypt says they should. End of.
if passwords can be longer than what your hash algorithm takes, what method would you use to select the substring
You never select a substring from the input password. When presented with an input password longer than your main password hasher will deal with, run a fast pre-hash like sha512 over the whole input, then treat its (possibly truncated) output as the actual password.
-
You cut the password at the byte length of the hash algorithm input, and xor the rest of it (or next segment) with the previous data.
No you don't. Use a cryptographically secure input shortening hash, not a shitty ad-hoc one.
-
limit on tries (or severe throttling--"You must wait 1 hour before trying again") are far more important than raw password length.
The point of using long, hard-to-crack passwords is to guard against attacks where the cracker has their own copy of the whole password db, thereby rendering rate limits moot.
-
that's not how (most/modern) hash functions work. They take input of any length, and always change value if any bit in the input changes.
Bcrypt is atypical in that regard. It actually uses the secret input as an encryption key, then applies many many rounds of blowfish encryption, using keys alternating between secret and salt, to a well-known 128-bit starting text. The length of the output is the same as the length of the starting text, and the input secret is limited to the 448 bit size of a blowfish encryption key.
The point of bcrypt is to be thorough and CPU-expensive. It was specifically designed for use with passwords and pass phrases, not generating secure digests of arbitrary texts, which is why it can get away with having a limited maximum input length. The standard way of extending the use of bcrypt for longer inputs, should that be required, is to feed it with a cryptographically secure digest of arbitrary input. As long as the size of that digest is both larger than the 128 bits of bcrypt's own output, and shorter than bcrypt's input length limit, you lose no overall password hash entropy at all by doing that.
-
Steven Thomas's "Blowfish All The Things" cryptographic hash function
is nowhere near as battle-tested as bcrypt or the sha family. Personally I would not use it, and I am a Stephen Thomas.
-
It uses blowfish and SHA512, so it has both of those on its side.
-
On the downside, Steven Thomas can apparently neither spellar nor gramming, so I don't trust the quality of his work.
-
He also wrote the reference implementation in PHP.
-
On the downside, Steven Thomas can apparently neither spellar nor gramming,
he is being a little bit cryptic, give him a break
-
He also speaks proudly of battcrypt being faster than bcrypt given comparable inputs, which is odd given that the entire point of both is that they are supposed to be expensive to calculate.
Near as I can tell, battcrypt's main claim to fame is that it isn't bcrypt. Which makes it change for the sake of change, rather than a solution to an actual problem, and therefore properly ignorable.
-
> we had a minor denial of service bug in Discourse where we allowed people to enter up to 20,000 character passwords in the login form, and calculating the hash on that took, uh … several seconds
Which only goes to show that @codinghorror was, as ever, was Doing It Wrong. A sha-family pre-hash feeding bcrypt is relatively time-insensitive to input password length, because the bcrypt step (given a properly chosen work factor) is always going to be orders of magnitude slower than the sha input-length-reduction step (which can in most cases actually be done client-side with zero additional security risk).
-
And another thing, while all these little tykes still seem to be scattered around the lawn: I am sick to death of reading endless advice from well-meaning people on "choosing a good password". It has been the case for years that any unique site password you're likely to be able to remember with your own brain and fingers is going to be too weak to resist offline cracking.
Use password management software (KeePass, LastPass, Password Safe, 1Password, whatever). Let that software generate and remember the unique passwords you supply to your online services. Generate a long random master passphrase for your password safe, write it down, store the written copy somewhere physically secure, and practise typing it repeatedly over several days until it goes in your muscle memory. Let the pain of that practice be your incentive to keep your devices keylogger-free. Congratulations! You are now among the tiny minority of people who don't have to worry about online identity theft.
-
I just use Google Chrome's password manager. I don't need a master password because if someone is able to log into my computer or has physical access to my computer, they can just go read my email and reset all my passwords anyway. It's not like I'm losing any security by not having a second layer of security for accounts I'm not currently logged in to.
-
I just use Google Chrome's password manager.
If it can generate random unique passwords for you, and you're happy with its level of protection against personal password database access by black hats, then that's a perfectly sensible thing to do.
-
It uses blowfish and SHA512, so it has both of those on its side.
Spoken like a true cryptographer!
-
if someone is able to log into my computer or has physical access to my computer, they can just go read my email and reset all my passwords anyway.
For what it's worth, this is not the case for me because I do not allow any of my email clients (web or otherwise) to store my email password; that's KeePass's job.
-
For what it's worth, this is not the case for me because I do not allow any of my email clients (web or otherwise) to store my email password; that's KeePass's job.
Still, if someone has physical access to your computer, he can just install a keylogger and you're f*cked anyway.
-
No sufficiently skilled attacker can be defended against indefinitely, because "sufficiently". Reducing my attack surface to "devices upon which I am likely to enter my KeePass passphrase" puts the likelihood of attack well below my personal threshold of concern.
-
Yeah, but my point is that you cannot reasonably defend against an attacker who has physical access to your computer anyway, so there's not point in trying to do that. (Except from setting a password for your user and locking your screen when you leave your laptop to protect it against "funny" coworkers' "jokes".)
Reducing my attack surface to "devices upon which I am likely to enter my KeePass passphrase" puts the likelihood of attack well below my personal threshold of concern.
Those are the same devices you read your emails on, right?
-
-
Mostly. What of it?
So it still doesn't make sense to disallow the email client to save the auto-generated password because the client is about as safe as the Keepass instance on the same computer.
-
That does not help your argument
-
it still doesn't make sense to disallow the email client to save the auto-generated password because the client is about as safe as the Keepass instance on the same computer.
Actually it isn't. Gaining my KeePass password via keylogger requires covert physical access to a computer that I am going to use. Gaining my email account password by reading it out of an email client's local store only requires physical access to a computer that I have used.
But this is a pretty subtle distinction. Really the main reason I use KeePass for all my password storage is to make sure that I frequently need to type its master passphrase, which keeps it nicely in muscle memory. If I were only to use KeePass to manage access to services I use less frequently than email, there's a good chance I would forget the master passphrase and need to go find my paper backup of it, which will in general not be within walking distance of where I am.
-
The point of using long, hard-to-crack passwords is to guard against attacks where the cracker has their own copy of the whole password db, thereby rendering rate limits moot.
Ah, but therein lies a huge problem, because with dictionary attacks, if the cracker has the password DB, they will break passwords. No matter how "good" they are, because there will always be a slew of passwords that aren't good enough.
If cracker gets password db, all you can do is cross your fingers and ask everyone to change their passwords, hoping the damage isn't too great. Insisting on long passwords to protect the password db is therefore futile...if you don't protect the password db.
-
If the cracker gets the password DB, but there are other password DBs that are also gotten by the same cracker and they have easier encryption to brute force, you're safer than you would be if you had the easiest encryption to brute force.
You don't need to be the strongest, just not the weakest.
-
there will always be a slew of passwords that aren't good enough.
which is exactly the point of being one of the people who uses passwords that are good enough.
-
You don't need to be the strongest, just not the weakest.
Security by "I don't have to outrun the bear, I just have to outrun you"
-
No you don't. Use a cryptographically secure input shortening hash, not a shitty ad-hoc one.
Fair enough, though I was under the impression this was what hashing algorithms like SHA256 did in order to fold data.
I was attempting to give a simple way to fit the binary data that was better than simple truncation. I've edited the post to correct this.
-
I am sick to death of reading endless advice from well-meaning people on "choosing a good password".
Me too. Actually password strength isn't all that critical... as long as you never reuse a password. Not reusing passwords makes offline attacks pointless (who cares if they get your password to site X if they stole the database to site X). Reasonably secure passwords are strong enough against online attacks.
-
as long as you never reuse a password
Quite so, and password management software also makes doing that not only practical but the easiest option. And once you're using password management software, there is no longer any reason to avoid the use of longer rather than shorter per-service passwords.
There seems to be a widespread perception amongst the technological priesthood (of which I count everybody on this forum as a member) that the non-technical wider public is simply too stupid to understand what password management software does, from which it follows that recommending its use is a waste of time.
That hasn't been my experience.
Yes, there will always be people who nod and look concerned and still use 123456 or password for every service they log into. But these are the same people that are going to ignore well-meant advice about "choosing strong passwords" because doing that seems too hard.
https://www.youtube.com/watch?v=yzGzB-yYKcc&t=2m26s
The simple fact is that most casual computer users simply have no idea that password managers are even a thing, and react to an in-person live demonstration of same with "wow, that's pretty cool". Most of the people I talk to in person about this stuff instantly get the analogy between a password safe and a keyring, once it's pointed out that such software even exists. They also intuitively grasp why using the same key for every single lock might be a poor idea, especially when that universal key is actually just a bent hairpin.
If the aim is to give advice that has some chance of improving security for some people, then it seems to me that such advice ought to reflect best current practice - and "choose longer passwords" or "use passphrases instead" is a very long way from that. We should all be singing from the "use a password manager" hymn sheet with voices raised high.
-
If the aim is to give advice that has some chance of improving security for some people, then it seems to me that such advice ought to reflect best current practice - and "choose longer passwords" or "use passphrases instead" is a very long way from that. We should all be singing from the "use a password manager" hymn sheet with voices raised high.
The sad thing is that there are many services that make integration with a password manager downright noxious, if not impossible.
-
Oh, absolutely.
It's incumbent upon all of us to respond to PHB requirements for such things with flat refusal.
Filed under: you will take my ability to paste into a password field from my cold dead etc
-
Security by "I don't have to outrun the bear, I just have to outrun you"
That's generally true of security though - having the strongest attracts attention, which is eventually more likely to get you hacked.
-
I was under the impression this was what hashing algorithms like SHA256 did in order to fold data.
If that were actually true, it would be trivial to generate SHA256 collisions on demand. It isn't. Therefore, that's not actually true.
-
There seems to be a widespread perception amongst the technological priesthood (of which I count everybody on this forum as a member) that the non-technical wider public is simply too stupid to understand what password management software does, from which it follows that recommending its use is a waste of time.
I have personally been unable to convince my wife and daughter to use one. I'm certain that they aren't too stupid, but they find it less convenient than just using their browser's password management. This leads to more password resets over time, of course. And re-used passwords. AFAIK, they've been lucky and not had anything compromised so far.
We should all be singing from the "use a password manager" hymn sheet with voices raised high.
Man...I try.
-
Little ms. flabdablet is ten years old, and she's the only member of my household I've had success with in this regard.
-
The sad thing is that there are many services that make integration with a password manager downright noxious, if not impossible.
That's why I use medium security 8 character passwords, I also discard passwords until I get one without 1, l, I, O, or 0. They aren't too bad to type if integration doesn't work. As I said earlier, as long as all passwords are unique, you don't care much about offline crackability of your password.
-
there is no longer any reason to avoid the use of longer rather than shorter per-service passwords.
Except, of course, the idiotic services that force you to use a short password from a restricted character set, may they die in a fire and rest unpeacefully in eternal torment.
The simple fact is that most casual computer users simply have no idea that password managers are even a thing
I admit that I was unaware, or only vaguely aware, of them before I started reading TDWTF. It took a little while to convince me that they are a good thing ("What if the password DB is stolen?"), and even longer to convince me that they were of sufficient benefit to be worth the bother, but I am now a firm believer and evangelist.That said, there are a few accounts for which I still use unsafe passwords. If the only thing the password does is allow somebody to download free game content without registering their own free account, who cares that it might be vulnerable to a dictionary attack or work on multiple sites?
-
If the only thing the password does is allow somebody to download free game content without registering their own free account, who cares that it might be vulnerable to a dictionary attack or work on multiple sites?
Bugmenot is a beautiful thing :D
