5

It seems to me that whenever I register on a website, there is absolutely no guarantee that the administrator will not be able to decrypt and view my password (if they even bother encrypting my password in the first place).

Is there any way to know how securely my password is being stored on a standard website login?

Obviously the best way to protect against this is to use a different password for each site, however that's not the question I'm asking.

BenAdamson
  • 235
  • 1
  • 4
  • One possibility to avoid such problems is to look into using OAuth2, so create an account/login using Google or Facebook. Of course, most websites don't offer such capability. – Alexis Wilke Aug 04 '18 at 22:39

1 Answers1

10

If the admin really wants to see your password, then he will be able to do so. He just has to grab it when you send it to the server.

If you want to know what password-dependent data is stored on the server side, then that's another question. In general, you cannot know how they do things, but sometimes you get clues. Basically, the reasonable thing to store is a "password verification token" which is a hashed version of the password, using a proper password hashing function. If they do that, then they cannot retrieve the password and send it back to you. Thus, if there is a "password modification screen" that can show you your password, or if they send back your password to you by email when you click on the "I forgot my password" button, then you know that what they store is unreasonable. Plain Text Offenders is a rage/shame Web site that gathers reports of such occurrences, mostly for being able to point and mock these poorly developed sites.

What you cannot really know from the outside is whether, when they store only hashed passwords, they use a proper password hashing function, or something else. You usually learn how poorly they did things when they get breached in and a list of hashed passwords is extracted: if the passwords get broken at a rate of dozens per second, then the hashing function was quite bad...

Password reuse is too dangerous. You should use a new, specific password for each site -- that way, any ineptitude on their side will be contained to that specific site. To remember all these passwords without having an enormously efficient brain, you may want to use a password manager software, e.g. KeePass.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Thanks for the solid answer. I got burnt a few years ago when 000webhost (awful company) got hacked - they had stored all passwords in plaintext, and even had the stupidity to email me my password when I registered. This was before I started using LastPass for password management, and at the time wasn't really using more than one or two passwords. – BenAdamson Mar 09 '16 at 15:30
  • A system I have to interact with can't (or won't) send me my password but is cheerfully NOT case-sensitive. I suppose it could have been `ucase()`d before being hashed. – Andrew Leach Mar 09 '16 at 15:33
  • You say to store a "verification token" but you would have to create the token on the server, in order to store it, so the password has to make its way to the server. If not, then you are hashing on the client, and that presents "pass the hash" issues, so I am curious your thoughts. Also, if the token is created on the client, sent to the server, and then hashed on the server, it would still be possible to grab the plain text, no? – XaolingBao Dec 26 '16 at 21:48