Storage of account password on PMDG servers

[SjotgunSjonnie 0]

Dear PMDG, On ordering the 737NGX I had to retrieve a password using the password retrieval service. In the that was sent to me I noticed that the password I entered originally was sent to me. This, as you may be aware of (there are sure to be some smart software engineers in your company) is risky from a security perspective in various ways: (1) E-mails which you send out are visible to all. If someone is listening to internet traffic at one point in the communication chain he will see my password.(2) By sending me my originally entered password, it seems that you are storing this password either in a plain text or encrypted format. If the system holding the password is compromised, so is my password. Of course you are probably aware of the need for hashing the password and applying a salt onto it, so please do. Note that I found this to be so much of an issue that I'm writing this message before installing the PMDG 737NGX I just purchased. I hope you can resolve this issue soon. Kind regards, David Walschots

[Tabs 2,790]

1. If someone's outside packet sniffing you to get your PMDG store password, you have much bigger problems I think. It probably should send a link to reset it though, but I don't know if that's an option in the cart system. (couldn't someone just sniff that link, which has to come in plain-text, under the same type of logic and get to it before you to reset it?) 2. The passwords are encrypted/hashed/salted on the server, they're not plain text.

[SjotgunSjonnie 0]

(1) Consider the case where certain types of traffic from certain domains are sniffed on purpose by some evil party. E.g. people would want to harm your business by sniffing for passwords you send out to them and abusing them. Then sure, the link would also be usable by them, but only between the moment of capturing it and resetting the password, not during the duration of the password´s lifetime. (2) If you hash my password you would not be able to send my original password back to me, as hashing is a one-way operation. Therefore, your statement is false.

[Tabs 2,790]

I know we are not storing passwords in plain text on the server - maybe I misunderstood what you meant. I will ask about this, but it is not high on the priority list right now.

[Guest]

(1) Consider the case where certain types of traffic from certain domains are sniffed on purpose by some evil party. E.g. people would want to harm your business by sniffing for passwords you send out to them and abusing them. Then sure, the link would also be usable by them, but only between the moment of capturing it and resetting the password, not during the duration of the password´s lifetime. (2) If you hash my password you would not be able to send my original password back to me, as hashing is a one-way operation. Therefore, your statement is false.

Technically speaking you are right.

[aentwis 61]

I had to go through this process. Frankly, the current setup is insecure, as the password sent to me by e-mail was plain text. This implies that the pw is stored on some system in plain text. It may be some root access only file, but I should only have the ability to have the password reset. At the end of the day, there are some personal data of value to identity thieves. I am aware of the fact that payment details are not stored on your systems as has already been mentioned, but I would be annoyed if someone got hold of my download and used it. Would be nice to have a little more security built into the customer accounts. Andrew

[Techinica 0]

(1) Consider the case where certain types of traffic from certain domains are sniffed on purpose by some evil party. E.g. people would want to harm your business by sniffing for passwords you send out to them and abusing them. Then sure, the link would also be usable by them, but only between the moment of capturing it and resetting the password, not during the duration of the password´s lifetime. (2) If you hash my password you would not be able to send my original password back to me, as hashing is a one-way operation. Therefore, your statement is false.

Regarding 1, such an attack is 99 times out of 100 going to occur on your own network, and being as though you seem so security conscious, you'd be aware that its recommended to have a unique password for each service/website. As such we're only talking about compromising one password. Regarding 2, whilst you say that hashing is a one-way operation, and you're correct, encryption is definitely not. I'd suggest they're storing your password using something like AES-256 and simply decrypting it to mail it back to you.

[Guest]

As such we're only talking about compromising one password.

That's right the point but that's not a good reason to let her get used by someone different from the owner.

[SjotgunSjonnie 0]

Regarding 1, such an attack is 99 times out of 100 going to occur on your own network, and being as though you seem so security conscious, you'd be aware that its recommended to have a unique password for each service/website. As such we're only talking about compromising one password. Regarding 2, whilst you say that hashing is a one-way operation, and you're correct, encryption is definitely not. I'd suggest they're storing your password using something like AES-256 and simply decrypting it to mail it back to you.

(1) I agree with your statement on having separate passwords per site. But one cannot expect non-tech savvy users to know or follow this recommendation. (2) The fallacy here is that the key used to encrypt and decrypt is located on a system which may be compromised. Therefore, the act of encrypting information provides only security by obscurity, which as we know is not secure at all. In the end the question really is: why take the risk at all?

[Guest]

Dutch, what's your opinion on recent d.o.s. ?

[SjotgunSjonnie 0]

I am no security expert, simply a software engineer. IT system security is simply about thinking about all defensive layers which can possible reduce the effects of an attack. Hashing a password is such a defensive layer (but don't forget the salt, to prevent rainbow table attacks). This principle is called defense in depth. PMDG, please consider these links.http://stackoverflow.com/questions/674904/salting-your-password-best-practiceshttp://stackoverflow.com/questions/536584/non-random-salt-for-password-hashes/536756#536756

[Techinica 0]

The fallacy here is that the key used to encrypt and decrypt is located on a system which may be compromised. Therefore, the act of encrypting information provides only security by obscurity, which as we know is not secure at all. In the end the question really is: why take the risk at all?

Hashing and salting isn't exactly safer either, especially with older algorithms such as MD5 or SHA1. Collisions in certain types of hash algorithms can be generated exceptionally quickly with today's modern GPU's, even a SHA512 hashed string 'could' potentially have a collision found in seconds... As you say, there's many layers involved and hashing basically just buys you time to make sure anything that's been compromised can't be used before you've been able to re-hash (i.e. forcing users to change passwords etc), but by and large the most important thing is making sure the data doesn't get stolen in the first place by securing the machine/s in question properly, which I'm sure PMDG has taken the steps to do. What I guess you're actually getting at with the thread however, and what PMDG should consider implementing instead is a password reset system in which the system either generates and sets a new password before mailing it out OR sends a link to a page where the user can set a new password. That at least solves what you're saying about the original password potentially being sniffed and consequently used on other services.