582
Uh oh, somebody's not following best practices, that's a paddlin (thelemmy.club)
submitted 1 year ago by to c/cybersecuritymemes@lemmy.world
106 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 11 points 1 year ago (23 children)

I mean I guess in theory they could be sending the password to the backend and validating it against your hash? In reality I doubt anybody would do that tho as it's a huge load on the server

  • permalink
  • fedilink
  • source
  • hideshow 23 child comments
    •
  • [–] 2 points 1 year ago* (6 children)

    You could use logic to only send it after x amount of seconds without changes, waiting for the specified minimum length, etc.

    With the right restrictions, it really wouldn't be that much different load profile wise to submitting it upon button press.

    There's a high probability that it's sending the hash (or even the password 😵‍💫) to the browser and comparing it though which is bad practice. Hell, just having a hash with no salt is bad practice, and sending the salt to the frontend as well would be even arguably worse.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 1 point 1 year ago* (5 children)

    Not even remotely involved with opsec, but sending the password from the client to the server doesnt seem that crazy. It opens you up to people skimning your plaintext password if your connection is not secure, but by that same logic if your connection isnt secure then they can skim your hash. Unless the security on the site is good im sure there is a way to skip the encoding process and log in directly using the hash, so its a relatively small improvement to send the hash rather than plaintext, no? The much bigger issue would be if the server validated it as plaintext, because that would mean the server stores it as plaintext. But if the encoding is done server side, then that would make it significantly harder to crack the hash algorithm.

    Im sure im making a mistake with my reasoning here, can you explain it to me?

    Edit: ah, i see. I misread your comment.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 2 points 1 year ago (4 children)

    Yeah the password is usually sent, not in plaintext because you do it on a TLS connection. You can't do the hashing clientside and send the hash anyway because the value needs to be salted and you'd also be exposing your algorithm choice and other details, or you'd have to do further processing server-side where you could conceal the details in which case I don't really get what sending the hash gets you because you'd have to do it again.

    People seem to constantly forget in web programming that you can obfuscate the client code, but you can't actually hide it or rely on it solely for validation. The client isn't something you control. They can very easily bypass any validation you put in that layer.

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

    What is salting in this context?

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

    Using only hashes makes it possible to use what's called a rainbow table (essentially a database of common passwords hashed related to their plain-text values) to crack the hashed passwords if they're somehow retrieved from the database. A salt is a separate value, usually unique to each user, that is appended or prepended to the password prior to hashing it. That makes it much harder to crack the password, even if you have the hash in hand.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 1 year ago (12 children)

    The hash or a checksum can be sent to the page to be checked by the same function running in your browser that is checking if the new password has special characters etc.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 12 child comments
    •
  • [–] 13 points 1 year ago (10 children)

    That would be an extremely bad idea tho, because it would allow a malicious attacker to

    1. Try random usernames, and if the website returns a hash they know that user exists
    2. Once they have the hash, and the hashing algoritm, it is much easier to brute-force the password, bypassing any safeguards on the server

    Username/password validation should happen entirely server-side, with as little information as possible provided to the client

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 8 points 1 year ago

    Username/password validation should happen entirely server-side, with as little information as possible provided to the client

    Yyyup. This is why you also why it's good practice to respond with HTTP 404 if a public user has tried to access user data they shouldn't have access to, whether it exists or not. Don't give them the hint that they hit a path that has forbidden data.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 3 points 1 year ago (7 children)

    Username/password validation should happen entirely server-side, with as little information as possible provided to the client

    💯

    It's recommended practice to not even tell them which half of the username/password combination failed upon authentication failures.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 1 point 1 year ago (6 children)

    It is a password reset from. The username has already be confirmed in a previous step

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 1 point 1 year ago (5 children)

    That still doesn't make it good practice to send the old password (hashed or not) to the client.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 1 year ago (4 children)

    You are making an unfounded assumption that the password is sent to the client which does the check and then shows the message rather than the server doing the check and responding with the message back to the client.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 1 year ago (3 children)

    Nah I'm not, look above. There's a way to do this that isn't terrible. I just kinda assume that they aren't doing it properly because I've worked in software for decades.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 1 year ago (2 children)

    No one is reimplementing their hashing algorithm in JavaScript. Doesn't matter how many decades in the industry you have, that's a silly assumption.

    The parts of security here that involve best practices are invisible to the user. Things such as salting which many do not do but also how they handle the reset token which many do not think about.

    However, none of that makes a good meme for people cosplaying cyber security gurus.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 year ago* (last edited 1 year ago)

    Of course they wouldn't implement it themselves, that's what the wonderful world of npm is for. /s

    The software I've worked in is full of bizarre, dangerous junk. I used to assume that people did things at least the easier way if not the right way. Now, I expect them to do the dumbest, wrongest most esoteric thing possible and I'm often right.

    anecdote

    I once worked with a person that was essentially maintaining a series of statically compiled hashmaps by hand instead of, you know, doing the obvious and externalizing the fucking thing into a database table. The insane bastard even sat there incrementing the initial collection sizes when he got requests to add in new data.

  • permalink
  • fedilink
  • source
  • parent