103
RakNoel
3y

No! How about you go FUCK yourself instead? If you hash it then the length should NOT MATTER!

Comments
  • 18
    I agree with you about the issue, but at least they tell you there's a problem.

    I've once came across a website that accepted my password (28 characters, generated) but trimmed the last 12 characters without warning. Only found out about it when I tried to log in after a while.
  • 4
    @Jilano hahaha ye πŸ˜‚ Just learned it might be due to buffer overflow... but still maxsize of 50? Hmmm...
  • 4
    @Jilano This has happened to me on more then one site. Oh god it pisses me off. They could do some basic validation before submitting.
  • 7
    Wish I had devrant when they told me my password could not contain any numbers or special characters.
  • 2
    @RakNoel Some people just want to watch the world burn.
  • 15
    Nothing wrong in that. Even if its hashed in database, its not good to send lots of data to a webserver. Also, while the password is hashed, the cleartext password has to be stored in RAM initially, thus theres risk of buffer overflow. Same reason to limit which characters, to rule ut any vulns in webserver software.

    So a limit is a good idea. But not too short. I usually set my limit same as the byte length of hash, for example a SHA-256 password has a max of 32 characters.

    And here is the reason:
    An password longer than 32 characters on a SHA-256 is completely USELESS, as theres always one valid password that will hash to the same hash, that is shorter than 32 characters.
    Imagine you hash the value 00...x252...00, to 11...x252..11, then you will end up with all values 00..x252..00 to 11..x252..11, but in a random order.

    Of course, hashing a longer value, will make the hashes start repeating. Thus a bruteforcer will find the shorter password.
  • 1
    Get payback. Drop all their tables
  • 4
    Actually with default hashing 'settings', if passwords exceed a certain limit it will cause crashes πŸ˜…. But then you should also ask yourself what the fuck you're doing.
  • 3
    At least they said 3 less chars, and not invalid password πŸ˜’
  • 1
    @sebastian it matters because a good password is hard to bruteforce and easy to remember. A short password will likely be a dictionary, or some combo from rainbow tables, which makes bruteforce possible. Good passwords are passphrases. Nobody will ever bruteforce all combinations, so the existence of a non-memorable collision is pretty much irrelevant.
  • 0
    @sebastian might be because bcrypt takes too much time hashing longer passwords so devs put an arbitrary limit to prevent DoS attacks
  • 0
    @AndSoWeCode Yes but come on, 32 chars is enough, you don't need to write an entire book as your password.
  • 1
    @gitpush they said 3 chars left untill i had got the length under 30 and removed special chars...
  • 0
    @AndSoWeCode it was random gen.^^
  • 1
    @RakNoel Oh this is messed up :\
  • 0
    @linuxxx ...senpai, you're so fucking clutch😬
  • 2
    @sebastian What is enough should be the users' choice!
    @KidLaser
  • 0
  • 1
    I had seen a bug at a company where people were using the password field as a DDoS mechanism. Since unlimited length PW were allowed, people were uploading files to spam the server. And doing this with just a few hundred bots was completely feesible.

    That being said, 64 characters is probably still reasonable. 32... Maybe... Ehhh. 64 seems safer.
  • 1
    @meowth 64 is resonable if youre using SHA512. If you are using SHA256, then 32 is more resonable.
  • 1
    Length matters. Long passwords take much longer to hash if it's done properly. One can easily crash a server with just a long password. Limits must be placed. Unless the hashing algorithm differs depending on the length of the introduced password.
Add Comment