Admin,

cocospm is not being rude to you, and I didn't think his response at all aggressive. He's absolutely right to say that an "admin" supporting a networking and security device should understand enough not to suggest such ludicrous and incorrect ideas about password security. A few bit of searching on the web would put you on the right track.

It may be worth considering that many of your forum users will be networking and security veterans. Asking "Why do you want DNS Suffixes?" or "How else would you store passwords?" are really scary questions for us to be seeing an admin asking. It's hard to have confidence in a privileged position on a technical forum if the person doesn't have the pre-requisite knowledge to interact at a reasonable level of security and deployment knowledge, and the customer sensitivity to communicate more effectively.

It's wrong to accuse a customer of being rude, when what you are seeing is a very honest reaction to a shocking low level of knowledge. I think you might experience a substantially angrier and ruder response if you said something like this in person, outside the protective limits of a forum -- such as in a real-life Network Operations planning meeting in a major data centre. You'd be thrown out of the room.

cocospm wrote: If I sent a config file to Draytek I would expect it to contain, er, the router's configuration, with the passwords suitably encrypted.

A config backup is a config backup, and most commonly used as exactly that - a backup. If it didn't contain your passwords, which are a fundamental part of your backup, then it wouldn't be of any use to most users and the purpose they use it for. If I spilt coffee on my router and needed to restore to a replacement unit, or clone one config to another set of routers, again, I need a full config, not parts of it. If I want to play with settings but afterwards restore it back to how it was, I need a complete config. So, all in all, one would expect a completely config to contain a complete config. It might be that you could have the mechanism of a master password to encrypt all others, but that's a different matter (and perhaps a feature that coulld/should be added), but the passwords are still contained.

cocospm wrote: There is no need whatsoever for Draytek to know my passwords

Yours? Maybe not; I have no idea what technical problem you might have, so you could change them before sending, but in other people's cases, being able to reproduce with an exact config, whether it's a SIP account or PPTP host, it may be needed, especially when a pair of configs is sent. I'm sure the support dept. are very used to dealing with confidential/high privacy configs and would expect them to have strict controls/procedures in place.

cocospm wrote: and there is no reason whatsoever why a router would need to store my passwords in their original or, indeed, recoverable, form.

If a router stores a password, and it's not recoverable, by which I assume that you mean one that the router can retrieve it and turn it back into the plain password that can be submitted, then how would you expect that to work? It has to be a symmetric cypher. What else could the router submit to a service?

" Officer, here is my driving licence. I have shredded it, but honest, it really is me..."

jamessp1 wrote: cocospm is not being rude to you

"try to ensure you know even the slightest thing about security" is rude, plain and simple. And as for the rest, when did you promote me to being a network admin or a security expert? We are forum moderators here, that is all and most of my participation is as a user and learner just like everyone else.

jamessp1 wrote: It's wrong to accuse a customer of being rude

He's not my customer, and even if he was, why is it wrong? Wherever you worked, if a customer was rude, it should be pointed out and ask them to cease. I am sick of seeing that in my local supermarket or wherever "I'm the customer... I have special rights to be rude that I don't expect back.... The customer is always right...". Nonsense.

jamessp1 wrote: I think you might experience a substantially angrier and ruder response if you said something like this in person, outside the protective limits of a forum

Er....what's that got to do with it? We're in a discussion forum, so discuss or ignore. I simply asked "what would you expect the passwords to look like?". He might have just said "I haven't a clue, but I didn't expect plain text..."

Admin. Some thoughts for you. Assuming that we are just trying to make private passwords secure against casual exposure, safe for support teams to read, and survive a few months (or even years) of brute-force attempts, there are a number of options:

If you are convinced that there is no way to safely store passwords on a security appliance:

2. would you not expect the vendor to provide a archive facility that strips out all passwords and replaces the password values with a fixed string?


4. would you not expect the support organisation to alert their customers, and provide the information for the customer to remove the passwords manually by editing the insecure config files?


6. would there not be a massive business opportunity for someone to invent a mechanism to safely protect password files? Imagine what Cisco, Juniper, F5, Apple, Oracle, Microsoft, Google, etc, would pay to have rights to use such an incredible patent?


8. do you really think that no-one has ever thought about this problem and solved it?

How do other vendors solve this problem?
Embedded crypto either in the form of silicon (too expensive for Draytek) or as software (which is very low cost), and a two-way key encryption algorithm creates an encrypted password on the file system, and when the password is needed for an external application, then the password is decrypted by the original encryption key. Put simply non-exportable PKCS / X.509.

• The encryption store is not exportable/exported. It ideally sits on a different partition.


• If encryption store is zeroed out by an upgrade / full factory reset then users re-enter passwords after a config restore.


• The encryption store is not accessible on the file system by anything other than a privileged user account, unknown and non-configurable to admin.


• The encryption key can be created by a one-time hash of device characteristics: Using fixed and variable elements such as MAC addresses, CPUID, Time of initial config (+milliseconds) and a user installation phrase, etc.


• Using a Password store in the form of a wallet. Read up solutions like on Java wallet / Oracle wallet. It's just a vendor specific use of the principles involved in storing passwords securely on device (these wallets also store the keys off device, but that is not relevant to this discussion)

If you think that is too hard, Draytek already use certificates (and easy-rsa) and keys for ipsec and openvpn . So it's not a big jump to apply the same cert and key storage to all passwords. Just a bit more coding.

Out of interest, Government, Security Agencies and high security systems require:
[list=3]

[*] The encryption key to be held off device in an HSM (usually FIPS compliant)

[*] Use of a installation phrase to be manually added after re-boots, and all 2 way encryption keys are created an held in memory until next reboot.

[/list]

So there we are, some ideas, most dating back to the 1980's.

jamessp1 wrote: ...If you are convinced that there is no way to safely store passwords on a security appliance...

There is, but as I said, there is no way to store them in an assymmetric cypher (non-recoverable, as cocospm seemed
to expect), as otherwise one couldn't actually use them for any 3rd party logins/services, but they can be encrypted, yes.

How do other vendors solve this problem?

Your summary is correct; there are several methods, mostly involving a master password/key
which is not included in the config as I said earlier. It doesn't need specific silicon.

Admin, This is what you told the forum:

As the config is human readable (as opposed to binary) which allows editing, 3rd party scripting etc, what would you expect the passwords to look like?

The passwords cannot be encrypted with a one way hash because then the router would not be able to use the passwords when needed

There is, but as I said, there is no way to store them in an assymmetric cypher (non-recoverable, as cocospm seemed to expect)

So, again, how would you expect passwords to be stored in a script/config (non-binary) file?

The whole point here, (and you certainly didn't show a grasp of any of this in your early posts)

2. You didn't seem to think that warning other users was valid, in fact you suggested plain text passwords were normal.


4. Plain text passwords in a config are indefensible.


6. Allowing customers to send configs to support without appropriate information is indefensible.


8. The problem (as you put it) of not being able to store assymmetric keys is easily fixed by not including the keys with the config!!!!

You started this thread by telling us that we didn't know what we were talking about and "what else did we expect?" One-way hashes wouldn't work, and so plain text was what we should expect.

Then you pleaded ignorance and told us that we should be educating you.

You ended up telling everyone that you were right all along.

You still don't acknowledge that plain text passwords in configs are idiotic and devoid of an even rudimentary understanding of security, and easily fixed.

I'm frustrated with you because you have been absolutely no help. I'm working with support to try and get developers to change the storage of passwords. You haven't helped at all during this thread. So why interact in the first place? Isn't that the definition of a troll?