As a security engineer that manages multiple firewalls, I often negotiate the setup of VPNs with other organizations. It is a challenge, at times, to negotiate keying intervals and secure cipher settings between not so compatible firewall/VPN vendors; but the most difficult challenge has to do with the people factor: the Pre-Shared Key (PSK), also known as a Shared Secret. The Pre-Shared Key is used for the VPN endpoints to authenticate with each other and initiate a secure channel to negotiate the setup of the VPN tunnel. While certificates provide a more manageable alternative in large deployments, many security admins prefer PSK over certificates not just for the relative ease of setup, but mostly because of the lower CPU overhead.
So, back to the difficult part of PSK: how to securely communicate the shared secret. Obviously, email should NOT be used, unless you have the means to send/receive an encrypted message. Even if you can send through secure means, I would prefer to not have the shared secret archived on the corporate mail servers. This leaves us with the good old reliable telephone. When relaying a shared secret over the phone, copying a long complicated password is more prone to errors. This often results in security admins compromising security for convenience, using a shorter and less secure shared secret that is less prone to errors in relaying. We need a long, complicated secret. After all, which of these two shared secrets would you allow you to sleep better at night?
- aKindaLongPassword2016!
- WmjuBrsDOvBguaLQgDKAoG7153lVofXmpMp6rXhaN5gszOyUGVQ3s7aieBrol4iF
One evening, I was playing with one of the multitudes of online hash generators (that’s the sort of thing security geeks do, right?) and it occurred to me: What if I create a long password, email it to someone, and then we both use a hash generator to create a new password? The resulting password would not have been emailed. Perfect? Not quite. If my process is known to anyone, it can be easily replicated. I need it to be even more secure. The answer: HMAC; a keyed-hash algorithm that includes a secret key as part of the calculation. The result bears no resemblance to a hash without a key.
After emailing the initial password to “seed” the hash, I get on the phone and have the other person provide a much shorter password, say 16 characters – nothing too complicated or we are back to our original problem. We then use the short password as the HMAC key when hashing the seed password.
The PSK Solution: https://www.pskgen.com
Borrowing the javascript code from one of the online hash generators I was toying with, the IPsec PSK Generator uses the HMAC SHA-384 hash algorithm. Most hash generators output the hash in hexadecimal, but that means you have only 16 possible characters in your password – that does not provide very good entropy. Presenting the output in Base64 encoding uses 64 possible characters, providing much stronger entropy. Since Base64 groups the bytes in 6 bits, the resulting 384-bit hash is presented as 64 characters in length. This length combined with the 64 character space, the shared secret has 384 bits of entropy, which would take trillions of centuries to brute-force guess, even when using a large-scale attack.
You now have a shared secret that was easily exchanged without compromising security and has a high level of difficulty and pseudo-randomness.
There are numerous alternative methods for the exchanging the passwords to seed the PSK Generator. One idea is to have each person use a good random password generator to create a list of 10 or more long passwords and securely email them to each other. On the phone, agree on which password from one of the lists to use for the Password Seed and which password from the other list for the Key. Use your imagination and use various methods.