41

I recently forgot my password for our cable provider online account, only to discover that they sent it to us via plain text in an email. I quickly sent an email to customer support asking them if they were storing passwords in plain text in their database. I actually got a quick response back from one of their software engineers who said that due to the "application's design" it was necessary to hash the passwords in a recoverable format.

I didn't send an email back to ask if they were using a salt, but in general, I thought they were adhering to the lowest common denominator with regard to password security and recovery.

Am I in the wrong here? If they are using a strong encryption method, is this perfectly acceptable?

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
  • What is the potential maximum liability one account could accrue to the cable provider in a month? How many accounts do they manage? What is the technical sophistication of their customer base? – this.josh Jul 30 '11 at 04:43
  • 16
    "I can't get on the internet" "Don't worry sir, we e-mailed you your password." "…" –  Jul 30 '11 at 08:24
  • 1
    My previous ISP's password for connecting online was 11111111. My current password is similarly simple and obvious. Clearly the ISP doesn't believe the service really requires a password but the software asks for one. – Rincewind42 Aug 03 '11 at 11:38
  • 6
    Report them to [Plain Text Offenders](http://plaintextoffenders.com/). – TRiG Feb 15 '12 at 16:41
  • 1
    this is a somewhat interesting idea, but how could you get your password by mail if it is not recoverable? it may increase the security, but will probably kill the usability.. – jeremy-george Jul 18 '12 at 01:06
  • You could easily sent a link that allows the user to only change the password. Anyways most ISP's require a secondary email account NOT connected to your email provided by them. this easily could have been a comment, although even the quality of said comment, would need work. – Ramhound Jul 18 '12 at 16:11
  • 1
    Related: http://security.stackexchange.com/questions/4997/is-it-a-bad-idea-for-an-information-holder-to-e-mail-a-user-their-password – Steve Melnikoff Aug 24 '12 at 16:22

3 Answers3

45

For an ISP it is quite likely that they store your password in plain text or using a reversible encryption. This reversible encryption is not a hash as the answer claimed.

ISPs tend to not use one way hashes because a number of old protocols use the password as part of a challenge-response digest authentication.

Most notable is APOP, which is an extension to the old Post Office Protocol. In normal POP the username and password are transmitted in clear text, which is obviously bad. So people thought of an extension which prevented sniffing and replaying attacks: The server sends a unique identifier (for some strange reason it is called timestamp in the specification although it is more). The client concatenates this identifier and the password before calculating the MD5 hash. The server needs to do the same calculation, therefore it needs the clear password. This protocol is outdated; POP over SSL should be used instead. But it is still in common use.

Furthermore, ISPs often offer a number of services and getting all of them to use a central authentication mechanism is a huge challenge. So often passwords are replicated to those servers instead. Since this replication must be reproducible at any time for reliability reasons the clear text password is often stored. If a central authentication is not possible, it would still be preferable to store the different encrypted formats at the replication source instead of the plain password.

It is obviously extremely bad practice to give those passwords out to customers and first level support personal. Sending them in plain email makes it even worse.

Community
  • 1
Hendrik Brummermann
  • 27,118
  • 6
  • 79
  • 121
  • Many other protocols support SASL DIGEST-MD5, which if enabled would have the same problem as APOP. – user1686 Nov 23 '17 at 07:51
12

There are many protocols which require passwords to be stored in plaintext (or encrypted, but not hashed), for example HTTP Digest authentication, so there are legit reasons to store passwords in a recoverable format. Done right, this is acceptable. In the case of an exposed password store (and encryption key), most of the passwords can be recovered pretty cheaply even if they are hashed, so the difference isn't that great.

But, your description of their actions does not really sound convincing - it may be legit, but I wouldn't bet on it.

As a user, however, you should never trust that your password is not stored in plaintext (eg. visible to administrative people viewing your account), or that the service actually manages to keep the password safe. This means the normal precautions of not sharing passwords between sites and having the password be hard to remember by just glancing at it.

Nakedible
  • 4,501
  • 4
  • 25
  • 22
  • In such mechanisms, it is possible to use a hash as the password for the input and hash it before going through it. But for some reason we do not suggest that security practice to stop a server admin attack. – ewanm89 Jul 30 '11 at 11:01
  • Yes, it is possible to modify such schemes to have hashing in them, but obviously the implementations are no longer standard compatible after that. – Nakedible Jul 30 '11 at 11:22
  • 1
    Yeah, the question is, why on earth didn't we add hashing into said standards, look at any challenge/response standard, and they store a plaintext/reversibly encrypted password even though it's obviously an issue. – ewanm89 Jul 31 '11 at 16:59
  • Well, this goes off-topic for this question and could spring a really long discussion. In my opinion, two things: a) not everybody agrees that asymmetricity of passwords is important enough to warrant the complexity, b) it's a bit trickier to do it right with regard to all the attack models than naively thought, see for example http://www.iacr.org/cryptodb/archive/2006/CRYPTO/1869/1869.pdf – Nakedible Jul 31 '11 at 20:08
  • @Nakedible, that CRYPTO 2006 paper has nothing to do with the topic of discussion. It is talking about something different: PAKE protocols (which are indeed tricky, but are quite different than just hashing the password). – D.W. Aug 01 '11 at 03:49
  • 1
    The paper was just something to show how it is not trivial to add asymmetricity to an existing protocol without creating additional possibilities for an attack. Most protocols requiring plaintext passwords are meant to be used in an insecure communication channel, hence even passive attackers have to be taken in to account. And indeed, the method given in the paper solves the problem generically also for password-based authentication, even though there it is in the context of password-based key agreement. – Nakedible Aug 01 '11 at 04:41
7

ISPs, like everyone else, are vulnerable to insider attacks, external compromises, and social engineering, so the practice you describe is very bad. Most importantly they shouldn't be sending "you" your password - that is just too easy to socially engineer. They should reset your password and send you a token to log in and create a new one.

Beyond that, people reuse passwords despite all our efforts to encourage them not to, so any online storage of passwords puts users at risk.

As others note, there are some old protocols that require plain text, like APOP and HTTP Digest Authn, which probably explain these old internal processes. Microsoft has the same problem with some of its older systems. But those are bad protocols which should be eliminated, because of exactly these sorts of reasons.

Properly hashed reasonably-good passwords can indeed be protected from cracking.
See How to securely hash passwords? for how to do it (and how not to do it!)

Community
  • 1
nealmcb
  • 20,544
  • 6
  • 69
  • 116
  • 2
    Just as people reuse passwords when they shouldn't, most passwords people use are a far cry from reasonably-good. If the hashed form of a password is exposed, it is very likely that this hash can be cracked relatively cheaply, even if the password is hashed securely (even with scrypt). This means that if the hashed form of a password is ever exposed (to an admin, to customer service personnel, etc.), the exposed user should be instructed to change passwords. So, even though hashing is very good practice and is to be encouraged, the hashes need to be secured exactly as plaintext passwords are. – Nakedible Aug 01 '11 at 06:56
  • @nakedible I agree, at least if the system doesn't have good methods to reject bad passwords and help users pick good passwords. But there is still a big difference between the actual exposure of the user in the vast majority of cases (low-value targets), since most attackers aren't really persistent in spending the CPU time and energy cracking each password. What I'd like to see is some $/password figures for the various hashing options and distributions of password length/complexity. – nealmcb Aug 01 '11 at 14:51
  • I have a set of figures that I use, where I calculate the total cost of cracking a password by using Amazon EC2 computing resources. I find it nice to get a ballpark figure and because it totally skips the "time" aspect - a computing hour costs the same regardless if you use just one of them or 1000 at the same time (okay, just as a ballpark figure, reality differs a bit). I can send you a link privately, but I won't post it publically, atleast not yet. – Nakedible Aug 01 '11 at 18:59
  • @nakedible I'd love to see it - my email or whatever is pretty easy to find. I'd love to compare EC2 costs to the cost of using the sort of hardware that bitcoin miners use - optimized for hashing (see my bitcoin stats on the link above). When bitcoin gets less cost-effective to mine, I wonder how many will sell password hashing services, and what the going rate will be.... – nealmcb Aug 02 '11 at 02:56
  • I sent you an email, contact me if it didn't arrive. – Nakedible Aug 03 '11 at 08:47
  • @nakedible Thanks - got it and I'm looking thru it. Good stuff... – nealmcb Aug 03 '11 at 18:22