Many sites claim they aren't capable of viewing subscribers' passwords. How does this work? Is it mandatory?

1

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?

Selin Peck

Posted 2014-05-26T15:50:56.147

Reputation: 467

Question was closed 2014-05-27T22:32:12.710

Laws depend on country, I know the US does not have a law. – Scott Chamberlain – 2014-05-26T16:00:57.193

I see. Does that mean I shouldn't believe their claims that they weren't all capable of viewing the passwords, right? – Selin Peck – 2014-05-26T16:15:46.577

There's a site to post bad examples of what you describe: http://plaintextoffenders.com/

– TheUser1024 – 2014-05-26T18:00:43.513

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 http://blogs.msdn.com/b/ericlippert/archive/tags/salt/

– Eric Lippert – 2014-05-26T19:47:46.813

Answers

13

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.

Scott Chamberlain

Posted 2014-05-26T15:50:56.147

Reputation: 28 923

@ 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 – 2014-05-26T16:28:21.227

Yes that is hasing, but there is a lot more to it to do it "right". See the 2nd link. – Scott Chamberlain – 2014-05-26T16:31:02.147

@ 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 – 2014-05-27T14:24:38.173

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 – 2014-05-27T14:38:51.803

1Note 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 – 2014-05-27T15:58:48.500

3

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.

Federico Poloni

Posted 2014-05-26T15:50:56.147

Reputation: 295

Alternative methods can be implemented using JavaScript. – reinierpost – 2014-05-26T19:58:50.377

@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 – 2014-05-26T20:22:34.953