How to do Identity and Access Management Wrong.
This blog is a study in how to do Identity and Access Management wrong. I am going to pick on an organization that I am a member of known as (ISC)2. (ISC)2 is responsible for the certification and continued education of computer system information security professionals who bear the prod title (CISSP).
They are also the poster child on how to implement security in such a way that the system becomes unusable and unavailable because they are not terribly adept at identity and access management (one of the cornerstones of information systems security). So let us begin the critique.
We will begin with one of the most important and frequently one of the most poorly implemented aspects of identity and access management. Password management recovery. But before we begin discussing the flaws in the (ISC)2 implementation of password management recovery let's look at some more pervasive issues around passwords as an authentication factor.
In the Authentication space we use what are known as factors to enable a person to prove they are who they claim to be. These factors are 1) Something you know (such as a password, or the place you first kissed your wife...maybe) 2) Something you have such as a key, or a smart card, or a cell phone. 3) Something you are, such as your voice print or your retina, or your finger prints.
The problem with any set of factors is that all too frequently something you know becomes something you forgot, or worse yet something someone else knows too. Less frequently something you have becomes something you lost. And even less frequently something you are becomes something you aren't anymore. Loosing a hand for example, or an eye.
There is another factor which is seldom considered in the IT space but is sometimes used by government agencies such as the DMV, and this factor is someone who knows you. I have yet to see a decent proposal for a voucher system where other authenticated people can vouch for your online identity but if such a system were built then that might be yet another factor that could be used to verify your identity.
The Wall Street Journal published an article in 2017 entitled: The Man Who Wrote Those Password Rules Has a New Tip: N3v$r M1^d! Bill Burr was the author of "NIST Special Publication 800-63. Appendix A." The 8-page primer advised people to protect their accounts by inventing awkward new words rife with obscure characters, capital letters and numbers—and to change them regularly. This advice which Bill Burr readily admits was bad advice subsequently became part of many security standards such as the PCI standard, and is the advice that many people who are trained in security today still preach. Yet the author of this advice says this is bad advice. A newer revision to this publication was published in 2017 known as "NIST Special Publication 800-63B".
In the newer NIST publication they maintain that rather than using special characters to achieve adequate entropy in a password, it is more important to focus on password (or passphrase) length and to consider the human factors in designing a password rules. It says "Password length has been found to be a primary factor in characterizing password strength. Passwords that are too short yield to brute force attacks as well as to dictionary attacks using words and commonly chosen passwords."
They go on to say "Users should be encouraged to make their passwords as lengthy as they want, within reason. Since the size of a hashed password is independent of its length, there is no reason not to permit the use of lengthy passwords (or pass phrases) if the user wishes. Extremely long passwords (perhaps megabytes in length) could conceivably require excessive processing time to hash, so it is reasonable to have some limit ...
As noted above, composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [Policies]. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required ...
Let us now turn our attention back to the (ISC)2 Password management and recovery.
The first mistake that (ISC)2 makes is that they contract with a company called Okta and apparently Okta never got the memo that "P@$$w0rd$" are out and "Passphrases are in horray!" The second mistake they make deals with password recovery. While the (ISC)2 website has a password recovery link where you can enter your email to initiate a password recovery. Invariably what happens is you get an email from Okta that says the following:
Now if you follow the Sign-in Help page you are taken to a page which has a phone number you can call, but it doesn't do you any good since nobody picks up the phone. These 2 factors combined discourage the use of good passwords and tend to encourage the use of easy to guess passwords which makes the entire system more vulnerable. All in all their password recovery mechanism is not very scalable. In summary don't do what (ISC)2 does.
(UPDATE) They seem to have a functional password update link now, but the passwords don't persist. So basically they are using alternative factor authentication since you have to reset your password every time you visit the site. Also you have to use a shared email system like google since their reset mechanism won't work with a self hosted email system such as postfix. Basically their trust model is extremely weak by involving far too many third parties in the management of your authentication.
By the way the PCI standard does the same thing and the current PCI standard disagrees with the new NIST standard. PCI 4 is still in development and they claim that they will be aligning with NIST in some areas. PCI mandates that users change their passwords every 90 days NIST maintains that this is a bad idea. This increases the likelihood that they will be vulnerable to all of the risks that NIST points out with regard to selecting predictable passwords which are easily hacked, or choosing complex passwords that need to be written down.
There is a saying that 2 people can keep a secret if one of them is dead. Memorized secrets should never be shared with anyone. Passwords represent a shared secret, even if the service stores the secret as a hash, there is a period of time that the service has the password in memory and it could be compromised. This weakens the non repudiation principle severely.
It is shameful that in 2020 our security industry hasn't caught up with the 1970s yet. The year 1976 saw the public disclosure of both secure key exchange and asymmetric key algorithms. These technologies were quickly swallowed up into difficult to use authentication mechanisms such as kerberos, X509, and SAML. Which has led the followers in the IT community to think that PKI is a difficult thing to manage and implement.
But when you look past the difficult to understand standards currently in place, it is really quite simple. There are algorithms which let you generate 2 sequences of bytes called keys. You can use the algorithm encrypt a sequence bytes using one of the 2 keys. You can then take the same algorithm and decrypt the encrypted sequence back into the original sequence using the other key. One key is known as the public key and can be freely shared, the other key is known as the private key. This is known as asymmetric encryption.
There are other algorithms that let you take a sequence of bytes and generate a fixed length digest of those bytes that is for all intents and purposes unique to the input sequence. This fixed length digest is known as a hash. Take any text or binary file, and run it through a secure hash and you will get a fixed length digest usually 256 or 512 bits in length. This represents that text's unique number. In fact modern password secure storage mandates that passwords are stored as salted hashes of the password.
If you take a hash of a data string and then encrypt that hash using your private key, you can send your public key, the encrypted hash and the data string to someone else and they can prove that you had the private key by confirming that the encrypted hash decrypts to the same value that they get when they take a hash of the data. This is known as digital signing.
Another type of encryption is older and faster. It is known as symmetric encryption. Basically you have one key and you can use it to both encrypt and decrypt data. There exists a way to take a password and generate a cryptographically secure symmetric key.
PCI recommends that passwords are stored as cryptographically secure salted hashes. They do this because many data breaches start off with someone hacking a server that stores the passwords, and exfiltrating them. If you can grab the hashed passwords, you can begin to run dictionary attacks against the password database off-line. Authentication servers represent a rich target of opportunity for a hacker because they store lot's of peoples secrets. People are supposed to use a different hard to guess password on every site they register with, but they don't. Why? All the reasons identified above. Humans don't have minds that are capable of managing that many secrets. And bad password recovery makes the problem even worse.
But you don't need to store anything at all server side. Storing all that info even in encrypted form or hashed form is more risky by definition than not storing any of it. If a server is compromised all of the stored secrets are vulnerable to attack or exfiltration. Why not instead let a person keep their secrets to themselves?
This can be accomplished using the above technologies. First a user can use software to generate a public and private key. Next they can encrypt the private key for storage on their own computer using a symmetric key that is dynamically generated based on a passphrase that they never share with anyone. They can generate as many such private keys as they want and use the same password. To compromise those secrets someone would have to root their machine find and exfiltrate the encrypted private and then capture the password they use to decrypt the keys. This is hard and at the end of the day a hacker will put in all that work to compromise a single user. To pull off an attack on the scale of the Experian data breach they would have to rinse and repeat for each and every user they wish to compromise. This makes it much more expensive to get much less payoff.
To register with a service, the user simply provides the service their public key. The service associates their public key with their identity in the same way they associate their password with their identity today. Except that if a hacker steals the public key they have gained exactly zero advantage. No more does the authentication system become the single point of vulnerability for large sets of users.
When a user wants to authenticate with the service they can send a data file which contains their assertions about who they are. They can use their private key to digitally sign those assertions. They can send the assertions, the digital signature and the public key or its id, over an insecure channel and the party on the other end can confirm that the data-set came from the person to whom they have previously registered the public key.
The entropy over a public key is far greater than pretty much any password scheme out there and will stand up considerably better to brute force. If you continue to use all of the controls that are typically used to protect password authentication except forced password rotation, and you adopt digital signature authentication rather than password authentication you will never again have to worry about a hacker compromising your password database, you will end up with a much higher repudiation standard and the user can sleep safely knowing that their secrets are entirely under their control at all times.
They are also the poster child on how to implement security in such a way that the system becomes unusable and unavailable because they are not terribly adept at identity and access management (one of the cornerstones of information systems security). So let us begin the critique.
We will begin with one of the most important and frequently one of the most poorly implemented aspects of identity and access management. Password management recovery. But before we begin discussing the flaws in the (ISC)2 implementation of password management recovery let's look at some more pervasive issues around passwords as an authentication factor.
In the Authentication space we use what are known as factors to enable a person to prove they are who they claim to be. These factors are 1) Something you know (such as a password, or the place you first kissed your wife...maybe) 2) Something you have such as a key, or a smart card, or a cell phone. 3) Something you are, such as your voice print or your retina, or your finger prints.
The problem with any set of factors is that all too frequently something you know becomes something you forgot, or worse yet something someone else knows too. Less frequently something you have becomes something you lost. And even less frequently something you are becomes something you aren't anymore. Loosing a hand for example, or an eye.
There is another factor which is seldom considered in the IT space but is sometimes used by government agencies such as the DMV, and this factor is someone who knows you. I have yet to see a decent proposal for a voucher system where other authenticated people can vouch for your online identity but if such a system were built then that might be yet another factor that could be used to verify your identity.
The Wall Street Journal published an article in 2017 entitled: The Man Who Wrote Those Password Rules Has a New Tip: N3v$r M1^d! Bill Burr was the author of "NIST Special Publication 800-63. Appendix A." The 8-page primer advised people to protect their accounts by inventing awkward new words rife with obscure characters, capital letters and numbers—and to change them regularly. This advice which Bill Burr readily admits was bad advice subsequently became part of many security standards such as the PCI standard, and is the advice that many people who are trained in security today still preach. Yet the author of this advice says this is bad advice. A newer revision to this publication was published in 2017 known as "NIST Special Publication 800-63B".
In the newer NIST publication they maintain that rather than using special characters to achieve adequate entropy in a password, it is more important to focus on password (or passphrase) length and to consider the human factors in designing a password rules. It says "Password length has been found to be a primary factor in characterizing password strength. Passwords that are too short yield to brute force attacks as well as to dictionary attacks using words and commonly chosen passwords."
They go on to say "Users should be encouraged to make their passwords as lengthy as they want, within reason. Since the size of a hashed password is independent of its length, there is no reason not to permit the use of lengthy passwords (or pass phrases) if the user wishes. Extremely long passwords (perhaps megabytes in length) could conceivably require excessive processing time to hash, so it is reasonable to have some limit ...
As noted above, composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [Policies]. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required ...
Highly complex memorized secrets introduce a new potential vulnerability: they are less likely to
be memorable, and it is more likely that they will be written down or stored electronically in an
unsafe manner. "
Let us now turn our attention back to the (ISC)2 Password management and recovery.
The first mistake that (ISC)2 makes is that they contract with a company called Okta and apparently Okta never got the memo that "P@$$w0rd$" are out and "Passphrases are in horray!" The second mistake they make deals with password recovery. While the (ISC)2 website has a password recovery link where you can enter your email to initiate a password recovery. Invariably what happens is you get an email from Okta that says the following:
| Hi (username), |
| A password reset request was made for your Okta account. If you did not make this request, please contact your system administrator immediately. |
| At this time your password can only be reset by an administrator. To send them a request, go to your Sign-in Help page. Then click the Request help link. |
Now if you follow the Sign-in Help page you are taken to a page which has a phone number you can call, but it doesn't do you any good since nobody picks up the phone. These 2 factors combined discourage the use of good passwords and tend to encourage the use of easy to guess passwords which makes the entire system more vulnerable. All in all their password recovery mechanism is not very scalable. In summary don't do what (ISC)2 does.
(UPDATE) They seem to have a functional password update link now, but the passwords don't persist. So basically they are using alternative factor authentication since you have to reset your password every time you visit the site. Also you have to use a shared email system like google since their reset mechanism won't work with a self hosted email system such as postfix. Basically their trust model is extremely weak by involving far too many third parties in the management of your authentication.
By the way the PCI standard does the same thing and the current PCI standard disagrees with the new NIST standard. PCI 4 is still in development and they claim that they will be aligning with NIST in some areas. PCI mandates that users change their passwords every 90 days NIST maintains that this is a bad idea. This increases the likelihood that they will be vulnerable to all of the risks that NIST points out with regard to selecting predictable passwords which are easily hacked, or choosing complex passwords that need to be written down.
There is a saying that 2 people can keep a secret if one of them is dead. Memorized secrets should never be shared with anyone. Passwords represent a shared secret, even if the service stores the secret as a hash, there is a period of time that the service has the password in memory and it could be compromised. This weakens the non repudiation principle severely.
It is shameful that in 2020 our security industry hasn't caught up with the 1970s yet. The year 1976 saw the public disclosure of both secure key exchange and asymmetric key algorithms. These technologies were quickly swallowed up into difficult to use authentication mechanisms such as kerberos, X509, and SAML. Which has led the followers in the IT community to think that PKI is a difficult thing to manage and implement.
But when you look past the difficult to understand standards currently in place, it is really quite simple. There are algorithms which let you generate 2 sequences of bytes called keys. You can use the algorithm encrypt a sequence bytes using one of the 2 keys. You can then take the same algorithm and decrypt the encrypted sequence back into the original sequence using the other key. One key is known as the public key and can be freely shared, the other key is known as the private key. This is known as asymmetric encryption.
There are other algorithms that let you take a sequence of bytes and generate a fixed length digest of those bytes that is for all intents and purposes unique to the input sequence. This fixed length digest is known as a hash. Take any text or binary file, and run it through a secure hash and you will get a fixed length digest usually 256 or 512 bits in length. This represents that text's unique number. In fact modern password secure storage mandates that passwords are stored as salted hashes of the password.
If you take a hash of a data string and then encrypt that hash using your private key, you can send your public key, the encrypted hash and the data string to someone else and they can prove that you had the private key by confirming that the encrypted hash decrypts to the same value that they get when they take a hash of the data. This is known as digital signing.
Another type of encryption is older and faster. It is known as symmetric encryption. Basically you have one key and you can use it to both encrypt and decrypt data. There exists a way to take a password and generate a cryptographically secure symmetric key.
PCI recommends that passwords are stored as cryptographically secure salted hashes. They do this because many data breaches start off with someone hacking a server that stores the passwords, and exfiltrating them. If you can grab the hashed passwords, you can begin to run dictionary attacks against the password database off-line. Authentication servers represent a rich target of opportunity for a hacker because they store lot's of peoples secrets. People are supposed to use a different hard to guess password on every site they register with, but they don't. Why? All the reasons identified above. Humans don't have minds that are capable of managing that many secrets. And bad password recovery makes the problem even worse.
But you don't need to store anything at all server side. Storing all that info even in encrypted form or hashed form is more risky by definition than not storing any of it. If a server is compromised all of the stored secrets are vulnerable to attack or exfiltration. Why not instead let a person keep their secrets to themselves?
This can be accomplished using the above technologies. First a user can use software to generate a public and private key. Next they can encrypt the private key for storage on their own computer using a symmetric key that is dynamically generated based on a passphrase that they never share with anyone. They can generate as many such private keys as they want and use the same password. To compromise those secrets someone would have to root their machine find and exfiltrate the encrypted private and then capture the password they use to decrypt the keys. This is hard and at the end of the day a hacker will put in all that work to compromise a single user. To pull off an attack on the scale of the Experian data breach they would have to rinse and repeat for each and every user they wish to compromise. This makes it much more expensive to get much less payoff.
To register with a service, the user simply provides the service their public key. The service associates their public key with their identity in the same way they associate their password with their identity today. Except that if a hacker steals the public key they have gained exactly zero advantage. No more does the authentication system become the single point of vulnerability for large sets of users.
When a user wants to authenticate with the service they can send a data file which contains their assertions about who they are. They can use their private key to digitally sign those assertions. They can send the assertions, the digital signature and the public key or its id, over an insecure channel and the party on the other end can confirm that the data-set came from the person to whom they have previously registered the public key.
The entropy over a public key is far greater than pretty much any password scheme out there and will stand up considerably better to brute force. If you continue to use all of the controls that are typically used to protect password authentication except forced password rotation, and you adopt digital signature authentication rather than password authentication you will never again have to worry about a hacker compromising your password database, you will end up with a much higher repudiation standard and the user can sleep safely knowing that their secrets are entirely under their control at all times.
Comments
Post a Comment