![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
What I'm doing at work today
Maybe you've wondered what I do at work every day now that I'm in security. Well, probably you haven't, but this is giving me brain cramps, so I'll torture you with it anyway.
Like most large companies, we have a set of policy documents regarding security. Spread out over several sections, there are details regarding password management, like temporary passwords, password resets (if you forget your password), password length, password content (eg. not the same as your username), password complexity (eg. not all numbers; not all letters), password expiry (ie. change it regularly), password history (ie. don't reuse the old passwords), account lockout if you fail to login too many times, and protection of passwords during storage and transmission. I'm supposed to write up some text describing how one might approach designing a password management solution, which takes all of this policy detail and applies it) and today I'm struggling with password resets.
The policy says that users have to be positively identified before the password can be reset. The current solution today is to phone the help desk. What does the internal help desk know about me that allows them to identify me? Especially given that we have an internal employee portal and you can look up all my contact information including who my boss is. An alternate solution is to provide an automated mechanism for resetting passwords that the users can use for themselves.
For our customers, we ask them to set a security question and answer. If you can answer the question, we'll change your password, make the new password temporary, and e-mail you the text of the new password. This also isn't positive identification, which is one reason why we (a) make the password temporary, and (b) e-mail it instead of showing it to the person accessing the web page. It's not terrifically secure, but it mitigates some of the risk.
But wait, our policy says we have to securely transmit the password and is very specific that we mustn't send it via clear-text e-mail. Sooooo. What's a secure way of sending the password? We've established that the help desk, while sort of providing a secure transmission method (ie. over the phone), can only handle a weak authentication method. One secure way of sending the password is via the same automated mechanism that did the reset (probably a web page), but again we only have a weak authentication method. Splitting the request for reset and the password transmission method up helps to mitigate the weak authentication, but we have no choice but to send the password via clear-text e-mail. Encrypted e-mail is not generally available in the company.
What can we send via e-mail instead? We could send a link that just happens to contain a unique and temporary code. The web page with this link would then display the password and we could secure the web page with SSL. If we expire the temporary code in the link after a short time, say an hour or less, and if the code is large and random, say 64 alphanumeric characters, then we've followed the policy as well as we can. An important consideration in the design now is to ensure that the storage of the temporary passwords is secure. We absolutely must not encode the password in the 64 character code because discovery of the coding method would mean it was no better than sending the password via e-mail. That's a low risk, in my opinion, but it goes against the spirit of the policy.
But wait, the policy says that passwords must be strongly encrypted or one-way hashed when they're stored to the file system. So, now we need to encrypt the temporary password in order to protect it, even though it's temporary and we'll be removing the file in under an hour. We could build the system to encrypt using a configurable AES-256 key (meaning that we can change the key at need). Of course, now we have key management issues to deal with. How often do we change the key? Who has access to read or change the key? If the company already has a key management solution, does this need to be integrated with it?
Truthfully, I'd be tempted to violate the spirit of the policy in order to avoid having to deal with key management issues, but our "encoding" is probably just encryption so we haven't completely avoided the issue. The advantage would be that the system could use randomly generated keys that get rotated every hour (ha! automatic expiry of the old links!). No access to keys then that we need to worry about as they're only in memory and only for a short time. The other possibility is to go back even further and admit that sending the password via e-mail is probably not terrifically unsafe if you can be sure that it will be changed on the next login (which probably happens within an hour in most cases).
[Updated to add:]
An issue with using a randomly generated key is making sure that the randomness can't be guessed at. There was an issue with early SSL implementations (in the mid-90s) along these lines and it allowed someone to write a program that could predict what the key was for your SSL session and then read all the supposedly secure information being sent between you and the web site. Randomness is tricky to get right at the best of times. It's a nice simple word and there are almost no really good, 100% secure sources of randomness. In spite of what we might have been told. But we have some good approximations we can use that get refined over time. Still, this is actually kind of a stumbling block in the description above because it introduces an interesting and complex risk that's hard to mitigate at the level I'm discussing the issue.
Like most large companies, we have a set of policy documents regarding security. Spread out over several sections, there are details regarding password management, like temporary passwords, password resets (if you forget your password), password length, password content (eg. not the same as your username), password complexity (eg. not all numbers; not all letters), password expiry (ie. change it regularly), password history (ie. don't reuse the old passwords), account lockout if you fail to login too many times, and protection of passwords during storage and transmission. I'm supposed to write up some text describing how one might approach designing a password management solution, which takes all of this policy detail and applies it) and today I'm struggling with password resets.
The policy says that users have to be positively identified before the password can be reset. The current solution today is to phone the help desk. What does the internal help desk know about me that allows them to identify me? Especially given that we have an internal employee portal and you can look up all my contact information including who my boss is. An alternate solution is to provide an automated mechanism for resetting passwords that the users can use for themselves.
For our customers, we ask them to set a security question and answer. If you can answer the question, we'll change your password, make the new password temporary, and e-mail you the text of the new password. This also isn't positive identification, which is one reason why we (a) make the password temporary, and (b) e-mail it instead of showing it to the person accessing the web page. It's not terrifically secure, but it mitigates some of the risk.
But wait, our policy says we have to securely transmit the password and is very specific that we mustn't send it via clear-text e-mail. Sooooo. What's a secure way of sending the password? We've established that the help desk, while sort of providing a secure transmission method (ie. over the phone), can only handle a weak authentication method. One secure way of sending the password is via the same automated mechanism that did the reset (probably a web page), but again we only have a weak authentication method. Splitting the request for reset and the password transmission method up helps to mitigate the weak authentication, but we have no choice but to send the password via clear-text e-mail. Encrypted e-mail is not generally available in the company.
What can we send via e-mail instead? We could send a link that just happens to contain a unique and temporary code. The web page with this link would then display the password and we could secure the web page with SSL. If we expire the temporary code in the link after a short time, say an hour or less, and if the code is large and random, say 64 alphanumeric characters, then we've followed the policy as well as we can. An important consideration in the design now is to ensure that the storage of the temporary passwords is secure. We absolutely must not encode the password in the 64 character code because discovery of the coding method would mean it was no better than sending the password via e-mail. That's a low risk, in my opinion, but it goes against the spirit of the policy.
But wait, the policy says that passwords must be strongly encrypted or one-way hashed when they're stored to the file system. So, now we need to encrypt the temporary password in order to protect it, even though it's temporary and we'll be removing the file in under an hour. We could build the system to encrypt using a configurable AES-256 key (meaning that we can change the key at need). Of course, now we have key management issues to deal with. How often do we change the key? Who has access to read or change the key? If the company already has a key management solution, does this need to be integrated with it?
Truthfully, I'd be tempted to violate the spirit of the policy in order to avoid having to deal with key management issues, but our "encoding" is probably just encryption so we haven't completely avoided the issue. The advantage would be that the system could use randomly generated keys that get rotated every hour (ha! automatic expiry of the old links!). No access to keys then that we need to worry about as they're only in memory and only for a short time. The other possibility is to go back even further and admit that sending the password via e-mail is probably not terrifically unsafe if you can be sure that it will be changed on the next login (which probably happens within an hour in most cases).
[Updated to add:]
An issue with using a randomly generated key is making sure that the randomness can't be guessed at. There was an issue with early SSL implementations (in the mid-90s) along these lines and it allowed someone to write a program that could predict what the key was for your SSL session and then read all the supposedly secure information being sent between you and the web site. Randomness is tricky to get right at the best of times. It's a nice simple word and there are almost no really good, 100% secure sources of randomness. In spite of what we might have been told. But we have some good approximations we can use that get refined over time. Still, this is actually kind of a stumbling block in the description above because it introduces an interesting and complex risk that's hard to mitigate at the level I'm discussing the issue.
no subject