Jeff on mayonnaise


  • Winner of the 2016 Presidential Election

    At the end of the post, he slips in this little tidbit:

    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

    How the fuck did we not discover that one?


  • Winner of the 2016 Presidential Election

    @Jaloopa said:

    How the fuck did we not discover that one?

    Didn't we? I think someone did try. Just not enough times to DoS the site.


  • sockdevs

    @Jaloopa said:

    How the fuck did we not discover that one?

    /me sheepishly raises a hand

    i may have tried to create a sockpuppet with the entire text of a novel as its password....


  • Winner of the 2016 Presidential Election

    I remember posts that killed the site, nothing about entering absurdly long passwords though.

    This does <beg>raise the question, though: Anyone who knows anything about password security agrees that when a site tells you your 20 char password is too long, that site fails at security and shouldn't be trusted with anything more secure than the smell of your farts, but 20k is clearly a ridiculous limit as well. What should password length be limited to?

    @accalia said:

    i may have tried to create a sockpuppet with the entire text of a novel as its password....

    Fair enough. That does ring a bell now you mention it. Moby Dick?


  • sockdevs

    as i recall it was War and Peace, or at least as much of it as would fit in the password entry box.

    i might not have been the only person who did that though.


  • Winner of the 2016 Presidential Election

    @Jaloopa said:

    What should password length be limited to?

    I guess it depends on the hashing algorithm. Don't they all have a limit of how many characters they can realistically handle? I know that encryption key in bcrypt is 56 ASCII characters, including the terminator. So 55 characters sounds like a good number. Of course, we then get into the whole Unicode fun bit.

    Thinking about it, that might be the reason for the 20 character limit. It's a nice round number and it's close enough to 55 bytes if we allow for double-width Unicode characters. So if the system allows for Unicode in passwords, 20 doesn't seem that bad. I mean, can you imagine a non-programmer grasping the 55 byte limit without problems?

    There's also the option of discarding any characters (or maybe even bytes) past the limit, so you could keep it at 55 characters but strip any Unicode nonsense that goes over 55 bytes?

    Not an easy question in any case.


  • Grade A Premium Asshole

    @accalia said:

    as i recall it was War and Peace, or at least as much of it as would fit in the password entry box.

    That.

    Is.

    Awesome.


  • Winner of the 2016 Presidential Election

    @accalia said:

    /me sheepishly raises a handpaw

    You're slipping...



  • @Onyx said:

    I guess it depends on the hashing algorithm. Don't they all have a limit of how many characters they can realistically handle? I know that encryption key in bcrypt is 56 ASCII characters, including the terminator. So 55 characters sounds like a good number. Of course, we then get into the whole Unicode fun bit.

    Thinking about it, that might be the reason for the 20 character limit. It's a nice round number and it's close enough to 55 bytes if we allow for double-width Unicode characters. So if the system allows for Unicode in passwords, 20 doesn't seem that bad. I mean, can you imagine a non-programmer grasping the 55 byte limit without problems?

    There's also the option of discarding any characters (or maybe even bytes) past the limit, so you could keep it at 55 characters but strip any Unicode nonsense that goes over 55 bytes?

    Not an easy question in any case.

    Well, without salts, by keeping the byte length of the password below the length of the hash algorithm, you know all the byte maps that could have hashes associated with them, so you've made it easier to do a deterministic recovery of the passwords with a rainbow attack. You probably want the maximum password byte length to be at least 2x the length of your hash algorithm. Or just use per user salts that are the byte length of your hash output to force the wrapping of the map.



  • 200 characters?

    It's an arbitrary limit, yes. But it's long enough that any passphrase should fit in it, short enough that hashing it should not take any significant amount of time.


  • sockdevs

    @Onyx said:

    You're slipping...

    i didn't say it was my hand.

    :-P


  • Winner of the 2016 Presidential Election

    "Why not 201 characters?"

    "What's the difference?"

    "None. I just wanted to make it sound like I was listening"

    paging @Onyx


  • Winner of the 2016 Presidential Election

    Because it's a nice clean number.

    I'd personally put it somewhere like that too. If you have a password longer than 200 characters, well... https://www.youtube.com/watch?v=9A6_9Jk2djY


  • Winner of the 2016 Presidential Election

    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.


  • Winner of the 2016 Presidential Election

    Random, per password, start index?



  • @Onyx said:

    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.

    You cut the passworddata at the byte length of the hash algorithm input, and xor the rest of it (or next segment) with the previous data.

    Note: per @flabdablet (and I agree) this isn't a great way to do passwords, but you might use a technique like this for generating an object or file hash, depending on your requirements and hashing algorithms available. I don't hash things myself often, but my recollection is that most modern languages except javascript have crypto functions that take arbitrary length data anyway.


  • Winner of the 2016 Presidential Election

    @Jaloopa said:

    Random, per password, start index?

    So you store that in the DB and in case that gets stolen it helps... how exactly? Unless you have some magic that does something with that number in your code, it's in plain sight anyway.

    INB4: seed an RNG with it...

    @rad131304 said:

    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.

    Ah, ok, that makes sense.


  • Discourse touched me in a no-no place

    @Jaloopa said:

    What should password length be limited to?

    I restrict it to 72 characters.


  • Winner of the 2016 Presidential Election

    @Onyx said:

    So you store that in the DB and in case that gets stolen it helps... how exactly? Unless you have some magic that does something with that number in your code, it's in plain sight anyway.

    You're right. The number should be stringified, salted and hashed before storing it in the database. To reverse engineer the index, simply salt and hash numbers from 1 until you match the stored hash.


  • Winner of the 2016 Presidential Election

    The Bad and Evil Ideas Threads are :arrow_right: :arrow_left: :arrows_counterclockwise: :twisted_rightwards_arrows: and :arrow_lower_left: :arrow_double_up: :arrow_heading_down: :ok:, respectively



  • @rad131304 said:

    so you've made it easier to do a deterministic recovery of the passwords with a rainbow attack

    If you discover a shorter password that happens to hash the same - it will work. So, you can't really have much more entropy in the password that the hash can retain. You could use that for a maximum password. If you are storing 256 bit hashes, any more than 130 characters in the password will simply result in lost entropy. So, there's your max password length.



  • @Jaime said:

    If you discover a shorter password that happens to hash the same - it will work. So, you can't really have much more entropy in the password that the hash can retain. You could use that for a maximum password. If you are storing 256 bit hashes, any more than 130 characters in the password will simply result in lost entropy. So, there's your max password length.

    Password collisions isn't the issue you're trying to avoid with hashing - the discovery of the actual password BECAUSE of the collision is. If, even with a rainbow table, they can't be sure that the password they recovered is the byte code of the password, the hash collision becomes less useful.

    EDIT:

    The problem space I'm looking at is: hax0r has all the usernames and p@$$w0rds! because we failed security. Will they recover just the dumb user passwords and use them in other locations, or all user passwords? The shorter password might create a collision here, but it won't if my hash algorithm isn't the one someone else uses. They wouldn't be trolling to use the password against the new target site if they could get in any other way.

    I agree that no more entropy is added, but if they have to extend the attack 10x just to get 10 possible passwords, that's a security win, too.



  • :wtf:

    :hanzo: oh it's linked from there.



  • That's why the arrows were a good idea, and why some of us have custom CSS to put them back.



  • @Onyx said:

    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)?

    The hash algorithm begins with some initial state. Then it runs the compression function on the first m characters. The output of this operation is the new initial state for the next operation. Then it runs the compression function on the next m characters, etc. If the input to the compression function is less than m characters, it gets padded according to some scheme.



  • As long as the password "173467321476C32789777643T732V73117888732476789764376Lock" is allowed, all is right with the world.

    That's only 57 characters, but you need Patrick Stewart to read it out loud while you enter it.



  • Passwords should be stored as CLOB - allows 8TB+ in Oracle.
    Seems the Postgres alternative is TEXT which allows 1GB.

    Plenty of space for passwords :laughing:



  • My password is Crank 2: High Voltage. Not the title, but the DVD iso.



  • I scanned the entire Encyclopedia Americana to high-resolution bitmaps and use that.



  • @rad131304 said:

    Password collisions isn't the issue you're trying to avoid with hashing - the discovery of the actual password BECAUSE of the collision is. If, even with a rainbow table, they can't be sure that the password they recovered is the byte code of the password, the hash collision becomes less useful.

    But, if they use a password that the hash collides with the real password hash, then it doesn't matter. They've already logged in.

    Now, they have to do that PER user.

    But if they only need one login to do what they need to do, then game over.

    But most are looking for the algorithm so they can log into everyone's account.

    So anything past 130 no longer protects your own account, but simply protects everyone else's account.



  • @loopback0 said:

    Passwords should be stored as CLOB - allows 8TB+ in Oracle.Seems the Postgres alternative is TEXT which allows 1GB.

    Plenty of space for passwords

    No need -- hashing obviates having a long field to begin with.

    Filed under: War and Peace in 40 characters



  • @tarunik said:

    Filed under: War and Peace in 40 characters

    If you manage a two way hash of war and peace into 40 characters, then you need a nomination for nobel prize.


    umm.... actually it's possible to have a 1 bit hash of war and peace, as long as the algorithm only hashes war and peace.

    I'll leave that to everyone to figure out.


  • Winner of the 2016 Presidential Election

    @xaade said:

    If you manage a two way hash of war and peace into 40 characters, then you need a nomination for nobel prize.

    We're talking about passwords. Why would you want it to be two way in the first place?



  • @Onyx said:

    Why would you want it to be two way in the first place?

    Because if it's not two-way, then it's no longer war and peace.
    It's war and peace and hamlet simultaneously, depending on the algorithm.

    The cat is both dead and alive.

    OMG, quantum superposition is a hash.

    OMG, it IS the matrix.

    OMG, I suddenly understand the double-slit experiment.



  • @xaade said:

    umm.... actually it's possible to have a 1 bit hash of war and peace, as long as the algorithm only hashes war and peace.

    I'll leave that to everyone to figure out.

    bool myHashFunction(input)
    {
        return input === WAR_AND_PEACE;
    }

  • Winner of the 2016 Presidential Election

    Ok guys, @xaade has been drinking again. Who gave him the booze? You all know we agreed he's not allowed any more since the suppository thread.



  • what about using a number indicating the positin into the π decimals? (start,lenght)

    π has EVERYTHING into it!



  • but 20k is clearly a ridiculous limit as well. What should password length be limited to?

    I set mine to the number of bits in the hash digest. So: 256 or 512 bits.



  • @Jaloopa said:

    Anyone who knows anything about password security agrees that when a site tells you your 20 char password is too long, that site fails at security and shouldn't be trusted with anything more secure than the smell of your farts, but 20k is clearly a ridiculous limit as well. What should password length be limited to?

    Well, since 20 is clearly lame, why not 21 characters? :innocent:

    It's been talked about and talked about, but the reality is that even a short, decent password protects sufficiently if there is a limit on the number of tries. Take a 4-character numeric pin: If the debit card gets revoked after the 3rd fail, it's not very likely you'll break the pin unless the card owner chose something stupid like 1234.

    So limit on tries (or severe throttling--"You must wait 1 hour before trying again") are far more important than raw password length.

    @xaade said:

    If you manage a two way hash of war and peace into 40 characters, then you need a nomination for nobel prize.

    umm.... actually it's possible to have a 1 bit hash of war and peace, as long as the algorithm only hashes war and peace.

    You can hash anything to 1 bit. It's just that, if you hash lots of things, you'll kind of get a lot of collisions... :fearful:

    And, of course, it'll probably take the haxor only 2 tries to find a password that works.



  • No no, nothing that goofy.

    But I finally get superposition.



  • Must take quite a while to log in to any site.


  • Winner of the 2016 Presidential Election

    @CoyneTheDup said:

    Well, since 20 is clearly lame, why not 21 characters?

    It's more the fact that if it's restricted that much it's probably being stored in plaintext in a VARCHAR(20) column



  • @xaade said:

    But, if they use a password that the hash collides with the real password hash, then it doesn't matter. They've already logged in.

    Now, they have to do that PER user.

    But if they only need one login to do what they need to do, then game over.

    But most are looking for the algorithm so they can log into everyone's account.

    So anything past 130 no longer protects your own account, but simply protects everyone else's account.

    The maximum security of individual accounts on your service is the amount of entropy available in the hash algorithm (assuming you use hash sized per user salts), period. That has nothing to do with the amount of security provided in your database for the set of passwords after it's been stolen because, inevitably, you did something wrong (because the meat sacks always do). They are two separate concerns. The second problem the larger password length could (but probably won't) help you avoid is leaking PII - namely a user/password pair. Most people will probably use a password shorter than your hash algorithm, but why penalize those who want to use longer ones. The goal isn't entropy; it's forcing the thief to waste resources solving the problem. It's the same with key-stretching.

    As an aside, if you let someone brute-force throw passwords at your system until they accidentally collide with the "real" password which is longer than your hash, you've got other problems to deal with.

    Note: I'm not saying I think you, personally, would mess up your security, I'm saying most security failures are user errors.



  • @Onyx said:

    @accalia said:
    /me sheepishly raises a handpawhoof
    <!-- not empty -->



  • Only ManBearPig has a handpawhoof.


  • sockdevs

    Are you serial?



  • Super serial.


  • Winner of the 2016 Presidential Election



  • Just plug an RS-232 into me and be done with it.



  • @tarunik said:

    hashing obviates having a long field to begin with.

    Natch.
    Facts :barrier: jokes


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.