
Virgin Media - Your plain text passwords are safe with us - jbrooksuk
https://twitter.com/virginmedia/status/361753975738990592
======
dspillett
Unfortunately it is very common. The approach a lot of companies are taking to
telephone agents not knowing user's passwords is to ask for only three letters
of them - the agent on the phone needs to type these in to have them verified
- and this is not possible if the password is stored after processing with a
salted hash.

 _The reason this is done is that it reduces reply attacks which is a
significant concern for over-the-phone authentication. Using the three-
characters-from-your-password method someone listening in to your call won 't
be able to call back and authenticate as you unless they have listened in to
enough calls to piece together the whole password._

The usual method is to store the passwords in a strong but symmetric encoding
which is no more secure than plain text if an attacker can get both the stored
passwords and the key(s). the risk can be mitigated (though not completely
removed) by making sure the keys are never stored anywhere near where the
passwords are stored, but at some point in the process the key and the encoded
password must meet for at least a brief moment.

 _Essentially this becomes a problem of weighing one risk against another: is
the potential loss of security if the account data store is compromised
justifiable when considered against the likelihood of successful replay
attacks if you must hand over the whole password each time?_

One suggestion I've seen is to store (salted and hashed) each combination of
three characters without any external indication of which combination each
hash represents (so for abcdefghi you would store encodings of 01a02b03c,
01a02b04d, and so on, meaning 720 stored hashes for that ten character
password). That way you can check any combination by checking that the
resulting hash value exists in the set. This is probably not a good solution
though: if an attacker gets hold of the hashes then if they also know the salt
they only need 46,656 attempts to derive the content of each hash (assuming a
mix of numbers and single case letters is required) so 33.6 million checks
would guarantee revealing a 10 character password instead of 3.6 thousand
million million - reducing the processing requited by a factor of 100 million.
I say "probably not a good solution" as I've done no analysis of this
complexity compared to the relative non-safety of passwords stored in a
reversible encoding - though I assume the fact I've not seen any such analysis
from a trusted source either indicates that it isn't a solution relevant
experts feel should be taken seriously.

------
kfullert
I've asked them to clarify if they store them as plain-text, or if they're
encrypted (and can be decrypted by CSA when needed) ... if it is plain-text,
then I'll be taking my ~£80/month Virgin Media services elsewhere

~~~
thirsteh
There's virtually no difference between the two. It doesn't matter if you're
using the strongest encryption in the world: the system is automated, meaning
it has the encryption key in memory so it can validate passwords, the support
agents can read them, etc. An attacker doesn't care if it's plain text or if
they have to decrypt them with an encryption key that's easily accessible to
them.

If, instead, they were using a computationally expensive one-way function, a
"password hash function", then an attacker would be able to get the digests it
has produced, and maybe intercept a few live passwords as users log in, but
they would not be able to trivially dump all the clear-text passwords
wholesale. (Given the right password hashing setup, it is far too expensive to
do so.)

It makes a lot of sense to use one-way functions for passwords: you only need
to verify that a password is the same as the original (i.e. producing the same
output when passed to the hash function); you don't need to know/remember what
it is. There's no good reason for using encryption or storing them in plain
text--"easier customer support" certainly isn't one.

More information: [http://throwingfire.com/storing-passwords-
securely/](http://throwingfire.com/storing-passwords-securely/)

~~~
dspillett
_> the system is automated, meaning it has the encryption key in memory_

But it doesn't have to be in memory, or otherwise stored, anywhere near the
bulk account data. If the encrypted password is transferred up the application
layers to another physical resource that knows the key, and the passwords
(encoded and not) or _securely_ wiped from memory immediately after the
comparison then this offers some useful protection over plain storage. An
attacker would need to compromise both resources (the data store and the key
holder) in order to get hold of credentials. For this to be meaningful the
security of those resources and the communication between them must be very
carefully designed and implemented, but it is wrong to say symmetric
encryption is necessarily no better than credentials stored in plain form.

 _> There's no good reason for using [symmetric] encryption_

As per my other post
([https://news.ycombinator.com/item?id=6120089](https://news.ycombinator.com/item?id=6120089))
the reason this is done is to permit partial password checking which is used
to reduce the chance of successful reply attacks. Unless there is a way of
achieving both aims the decrease in risk (and to a certain extent perceived
risk) through stopping the replay attacks needs to be carefully considered
along with the decrease in risk through using storage methods that make this
replay protection impossible.

Of course security keypads as used by some banks (my mortgage provider uses
such a system) is a better solution, _if well designed and implemented without
cutting corners_ , but there are cost and convenience implications there which
may put off the companies (cost) or their customers (the inconvenience of
having a small device to not lose).

~~~
thirsteh
> But it doesn't have to be in memory, or otherwise stored, anywhere near the
> bulk account data. If the encrypted password is transferred up the
> application layers to another physical resource that knows the key, and the
> passwords (encoded and not) or securely wiped from memory immediately after
> the comparison then this offers some useful protection over plain storage.
> An attacker would need to compromise both resources (the data store and the
> key holder) in order to get hold of credentials. For this to be meaningful
> the security of those resources and the communication between them must be
> very carefully designed and implemented, but it is wrong to say symmetric
> encryption is necessarily no better than credentials stored in plain form.

If the system can automatically verify a password, i.e. decrypt it, then an
attacker can leverage that. You could design a system very carefully that
_might_ be invulnerable to memory injection attacks, _might_ not be on boxes
that have root escalation vulnerabilities, and which _might_ be using a secure
hardware security module--but why? You don't need to. Just use a one-way
function.

> As per my other post
> ([https://news.ycombinator.com/item?id=6120089](https://news.ycombinator.com/item?id=6120089))
> the reason this is done is to permit partial password checking which is used
> to reduce the chance of successful reply attacks.

Just add a PIN or something else that doesn't give you full access to the
account. No reason whatsoever to store passwords people use on many other
sites in what is, on 99.9999% of systems, equivalent to plain text.

------
jbrooksuk
There is a reply from someone called @Kaithar
([https://twitter.com/Kaithar/status/361765029848170496](https://twitter.com/Kaithar/status/361765029848170496))
which says "actually, DPA does mean they need to be able to read your account
password, the one setup for over-the-phone auth"

Surely that can't be true? DPA shouldn't give them the ability to read our
passwords, only the ability to save DOB, payment type (direct-debit etc) so
you can validate that. But not passwords.

~~~
kfullert
I think they need to store your "memorable name" in plain-text for DPA
purposes (so they can confirm they're talking to the account holder) but
passwords for e-mail/billing etc. online have no need to be plain-text

~~~
jbrooksuk
Well, when I signed up online to their service I created a password. A few
months later I went to login to figure out why our bill was so much but
apparently the account wasn't working. I rang them, didn't remember setting a
"phone password" so reset it then they said "Oh your password has been
blahblahblah and blahblooblah before". But I'd only have used them online. And
since I didn't remember setting it because they didn't offer me a "memorable
question" reset. They just read my online passwords out to me.

------
makethetick
I realised this not long after signing up with them. They don't even have a
separate 'phone password', the one they ask for (and sometimes read back) is
used for DPA as well as email (gmail based) login.

------
LaSombra
plain text != reversible, isn't it?

