Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Many sites claim they aren’t capable of viewing subscribers’ passwords. How does this work? Is it mandatory for websites which allow users to log in? Are there any protocols or laws which obliged them to store passwords in such a manner?

Also, how is this possible? Do they storing the users’ passwords on their servers in an encrypted format?

share|improve this question

closed as off-topic by Xavierjazz, Ramhound, Ƭᴇcʜιᴇ007, and31415, Breakthrough May 27 '14 at 22:32

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question is not about computer hardware or software, within the scope defined in the help center." – Ƭᴇcʜιᴇ007, and31415, Breakthrough
If this question can be reworded to fit the rules in the help center, please edit the question.

Laws depend on country, I know the US does not have a law. – Scott Chamberlain May 26 '14 at 16:00
I see. Does that mean I shouldn't believe their claims that they weren't all capable of viewing the passwords, right? – Selin Peck May 26 '14 at 16:15
There's a site to post bad examples of what you describe: – TheUser1024 May 26 '14 at 18:00
You might be interested to read my series of articles that describes the failings of a number of password systems, and arrives at a solution where the site does not need to ever know the original password. See – Eric Lippert May 26 '14 at 19:47
up vote 13 down vote accepted

All responsible companies should be hashing (the process to do what you are describing) passwords correctly (it is easy to do wrong); it is up to you whether you trust their claims.

There are laws about companies saying they do something and lying about it, but if they don't say whether or not they hash passwords, they are not forced to do it in the US unless it is covered by other laws such as PCI DSS or HIPPA compliance.

share|improve this answer
@ Scott Chamberlain : Thanks for the response. Is hashing the process of converting passwords to number string, that cannot be converted back to the original texts (real password)? I hope u get what I'm trying to ask.. – Selin Peck May 26 '14 at 16:28
Yes that is hasing, but there is a lot more to it to do it "right". See the 2nd link. – Scott Chamberlain May 26 '14 at 16:31
@ Scott Chamberlain : You referred to two sample organization who enforce such laws (PCI DSS and HIPPA). My question is, how could I know if a website is under such organization covered by law mandatory to do hashing on passwords? Is there a certification, seal, awarded to companies who are covered and obliged by such laws? – Selin Peck May 27 '14 at 14:24
HIPPA covers everyone who deals with medial records (hospitals, insurance, ect) PCI DSS is only required when a company collects and holds credit card information (just accepting credit card information and passing it on to a payment processor is not enough to be under PCI DSS). Neither require a business to notify customers that they are under those regulations. The only way to "know" is if they explicitly say it in advertising (false advertising is illegal) or you ask them privately and you trust them enough to believe the answer (them lying here may be illegal, consult a lawer) – Scott Chamberlain May 27 '14 at 14:38
Note to future readers: If your goal is to satisfy curiosity, Scott's answer is of course correct. If your goal is to implement such functionality yourself, the correct approach is to use an authentication framework written by experts. Security is especially difficult to get right. It's easy to have little bugs (as with all programming), but with security bugs there's little chance of noticing until it's too late. – Brian May 27 '14 at 15:58

When you insert a password and click on a "submit" button, the website you are sending the form to gets the password in plain text. There is no way around it, this is how HTML works. It is not an absolute necessity, as there are alternative systems, but they are not implemented in HTML or in browsers today as far as I know.

That said,

  1. the website seeing the password is not always the same site you are logging in to -- for instance, the Stack Exchange Network uses OpenID, which is essentially a way to delegate authentication to other "providers" such as Google or Facebook. In this case, your chosen OpenID provider (e.g. Google) sees your password and Stack Exchange doesn't.

  2. This happens at the moment of the login; responsible websites will compute a hash and then discard the password immediately. A hash is a sort of encrypted version of the password from which even they cannot recover the original in a successive moment after you have logged in. In other words, they store a certain function f(p) of the password; when you wish to log in again, they can read your new password q and check if f(p)==f(q), but they cannot get back p from f(p) (or, at least, it is considered a computationally unfeasible problem to do so).
    Whenever a website sends your password back to you in plain text, for instance in an e-mail, it's a big red flag that they are not handling security responsibly. As a user, though, in general you have no way to tell if they are throwing away immediately the plain-text passwords or keeping them, unless something like this happens.

  3. The method to keep you logged in a website relies on cookies and does not need storing your plain-text password anywhere.

  4. As you can infer from our answers, password authentication is problematic in many ways, so you should never reuse passwords. The best practice is relying on a password manager, where your random-generated passwords are protected by a "master password" that never leaves your computer.

share|improve this answer
Alternative methods can be implemented using JavaScript. – reinierpost May 26 '14 at 19:58
@reinierpost good point - but I do not know of any website that implements a system like this. A possible security concern is that you are getting the javascript code from the website itself, so this method does not really solve perfectly the problem "I do not trust the website" --- but in my view it would still be a step forward in terms of security, as would an additional layer in the browser that handles authentication properly. HTML5 contains everything and a kitchen sink, but not a standard secure alternative authentication method. :( – Federico Poloni May 26 '14 at 20:22

Not the answer you're looking for? Browse other questions tagged or ask your own question.