86
A question about passwords | characters used in them (programming.dev)
submitted 2 years ago* by to c/programming@programming.dev
64 comments fedilink hide all child comments
 

Why do so many companies and people say that your password has to be so long and complicated, just to have restrictions?

I am in the process of changing some passwords (I have peen pwnd and it’s the password I use for use-less-er sites) and suddenly they say “password may contain a maximum of 15 characters“… I mean, 15 is long but it’s nothing for a password manager.

And then there’s the problem with special characters like äàáâæãåā ñ ī o ė ß ÿ ç just to name a few, or some even won’t let you type a [space] in them. Why is that? Is it bad programming? Or just a symptom of copy-pasta?

you are viewing a single comment's thread
view the rest of the comments
[–] -1 points 2 years ago (1 child)

Well to be fair, if they're hashing serverside, they were doomed to begin with.

But yeah, there's a lot of ways to DDoS, and so many tools that just make it a 1 button click.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 2 years ago (1 child)

    Who isn't hashing server-side? That just turns the hash into the password which negates a lot of the benefits. (You can do split hashing but that doesn't prevent the need to hash server-side.)

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] -2 points 2 years ago* (2 children)

    Hashing on client side is both more private, and secure. All the user ever submits is a combined hash (auth/pubkey) of their username + password.

    If the server has that hash? Check the DB if it requires 2FA, and if the user sent a challenge response. If not, fail the login.

    Registering is pretty much the same. User submits hash, server checks DB against it, fail if exists.

    Edit: If data is also encrypted properly in the DB, it doesn't even matter if the entire DB is completely public, leaked, or secured on their own servers.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 3 points 2 years ago

    This means that the submitted hash is effectively a password. You get a minor benefit in that it obscures the original password in case it contains sensitive info or is reused. But the DB is now storing the hash password in plain text. This means that if the DB leaks anyone can just log in by sending the hash.

    If you want to do something like this you would need some sort of challenge to prevent replay attacks.

    This scheme would also benefit from some salt. Although the included username does act as a form of weak salt.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 2 years ago

    Per your edit, the DB being "encrypted properly" just means "hashing server side". There's little benefit (though not necessarily zero) to encrypting the entire database, since the key has to live in plaintext somewhere on the same system. It's also making the slowest part of most systems even slower.

  • permalink
  • fedilink
  • source
  • parent