5 ms·

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'l

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

jbrooksuk 13y ago
Sadly, I believed you'll be talking to the wrong people there. They'll wrongly assume they're safe as houses and passwords are safe, but in reality you're speaking to the Marketing team who think replacing passwords with is safe. I'm thinking of emailing them directly and asking the tech team. And if they're not securely encrypted then I too will be taking my services elsewhere. My calls, bank details etc are logged. I don't want potential hackers knowing my parents number so they can target them and everybody else too.
- kfullert 13y ago
  Do you have an e-mail address for a "technical" team as the Contact Us pages make it difficult to actually find out things like that
  - jbrooksuk 13y ago
    Sadly I don't. I've been looking for one, but only had 5 minutes. If you find one, please post here and tweet me @jbrooksuk I'll forward it on.
  - darkr 13y ago
    Yeah.. My experiences with Virgin Media tech (both business and residential arms) are that all job titles appear to be encapsulated by inverted commas.
thirsteh 13y ago
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 13y ago
  > 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 13y ago
    > 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.
rokusho 13y ago
Looks like I'm changing provider... If I could.

jbrooksuk 13y ago

Sadly, I believed you'll be talking to the wrong people there. They'll wrongly assume they're safe as houses and passwords are safe, but in reality you're speaking to the Marketing team who think replacing passwords with is safe. I'm thinking of emailing them directly and asking the tech team. And if they're not securely encrypted then I too will be taking my services elsewhere. My calls, bank details etc are logged. I don't want potential hackers knowing my parents number so they can target them and everybody else too.

kfullert 13y ago
Do you have an e-mail address for a "technical" team as the Contact Us pages make it difficult to actually find out things like that
- jbrooksuk 13y ago
  Sadly I don't. I've been looking for one, but only had 5 minutes. If you find one, please post here and tweet me @jbrooksuk I'll forward it on.
- darkr 13y ago
  Yeah.. My experiences with Virgin Media tech (both business and residential arms) are that all job titles appear to be encapsulated by inverted commas.

thirsteh 13y ago

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 13y ago
> 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 13y ago
  > 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.

rokusho 13y ago

Looks like I'm changing provider... If I could.