From c292872acde53ade1baf2ef49e38aeb305135497 Mon Sep 17 00:00:00 2001 From: Eric Christensen Date: Apr 15 2016 13:51:18 +0000 Subject: Moved main file to index --- diff --git a/Recommended_Practices_Authentication.adoc b/Recommended_Practices_Authentication.adoc deleted file mode 100644 index 2ed0610..0000000 --- a/Recommended_Practices_Authentication.adoc +++ /dev/null @@ -1,428 +0,0 @@ -Password Strength ------------------ - -Password authentication is the weakest authentication method available. -Unfortunately it is also the most prevalent and deceptively implement. -Password authentication only requires a single factor (something you -know) which in can be guessed by an attacker. Because of that, any -system that uses only password authentication needs to take multiple -issues into account to be secure. - -Because this authentication method is inherently weak it is important to -require high strength passwords (or change them often). - -Password entropy -~~~~~~~~~~~~~~~~ - -Password strength can be expressed as the amount of entropy present in -it. The easiest way to understand entropy in the context of passwords is -to think of it as "how easy it is to guess the password". Password that -is selected uniformly (that is, every value has the same chance of -getting picked) from a set of passwords that contain "1", "2", "3" and -"4" will have a probability of 1/4 = 0.25 of being chosen. Or to express -it in way that's similar to other values in cryptography, has 2 bits of -entropy (because -log2(-0.25) = 2 ). For longer passwords, it's easier -to just count the number of possibiltities and calculate the base 2 -logarithm to know its entropy. For example, passwords picked uniformely -from a set of all 8 character permutations of lower case letters will be -picked from a set of 26 * 26 * 26 * 26 * 26 * 26 = 26^6 = 308915776 -possible passwords. That means, that every such password will have -around log2(26^6) = 28.2 bits of entropy. - -Note that a password that is not picked uniformely (like is nearly -always the case with user chosen passwords) will have much more complex -entropy estimation. Let's change the previous example so that the -password "1" is chosen by half the users, and all the other passwords -are selected uniformely. That means the probabilities of the passwords -are "1" = 1/2, "2" = 1/6, "3" = 1/6 and "4" = 1/6. Alternatively, the -passwords have the following entropy estimates: "1" = 1 bit, "2" = 2.59 -bit, "3" = 2.59 bit and "4" = 2.59 bit. That's why a password that -consists of 8 lower case characters not necessairly has around -log2(26^8)=37.6 bits of entropy. - -Password guessability -~~~~~~~~~~~~~~~~~~~~~ - -Let's consider a system that only allows passwords that are single lower -case letter and the passwords are chosen uniformely by users. Your -chance that you won't guess such password in one try is 25 to 26 (which -is about 96%). But if you are given two tries to guess the password, -your chances of not guessing it are equal to 25/26 * 24/25 = 24/26 -(because to fail you have to fail guessing it the first time and fail -the second time, knowing already which password is wrong) or about 92%. -For three guesses, the chance of not guessing the correct letter in 3 -tries is 25/26 * 24/25 * 23/24 = 23/26 which is about 88.5%. In general, -for such password, given n tries, the probability you won't guess the -number is (26-n)/26. Now, if you want to know the probability that you -will guess the password in either first, second, third or n-th try, you -just need to substract the previous number from one: 1 - (26/n)/26 = -n/26. We can use this number in the same way as with the single guessing -case to calculate the level of security provided by the password when -the attacker is given n-tries to guess it: -log2(n/26). So, while -password in this system has about -log2(1/26)=log2(26)=4.7 bits of -entropy, a system that allows 4 tries before the password needs to be -changed has effective strength of about -log2(4/26) = 2.7 bits. In case -we have calculated the entropy of the password (in this case 4.7 bits) -and know the amount of tries the attacker can perform expressed in bits -(in this case log2(4)=2 bits), the calculation is a simple case of -subtraction: 4.7-2=2.7 bits. - -In general, a password with n bits of entropy on a system that allows m -login attempts before the account is locked provides n-log2(m) bits of -security. - -Alternative way to think about security of passwords is how likely it is -that the password will remain safe during its lifetime. A password with -10 bits of security in a given system has a chance of about 99.9% to not -be guessed. Password with 14 bits of security has a chance of about -99.99% to remain safe during its lifetime and so on. - -Practical recommendation -~~~~~~~~~~~~~~~~~~~~~~~~ - -There are two main ways to get a system in which the password is -unlikely to be guessed by attacker: use passwords that are simple (have -low entropy) but are changed often or use very complex passwords (that -have high entropy) and use them for long time. Optimal system should -detect which kind of password user selected and force user to change it -often enough to preserve security of system. - -While it is easy to say to require the users to pick passwords -uniformely ("really at random") from all 8 or 10 character permutations -of lower and upper case letters, digits and special characters to get -passwords that met chosen level of security it doesn't take the human -aspect of using such system into account. - -To aid users in selecting secure passwords the system can do two things, -limit how effective the attacker can be and to provide feedback of how -secure the password is and refuse use passwords with little entropy. - -Limiting the effectiveness of attacker should be done by two ways: by -limiting the rate at which the server itself can check the correctness -of the password (by hash stretching) and by limiting the rate or amount -of tries the attacker is given to guess the passwords. System which -allows testing if a guess is correct every 100ms will require for a -password that is used for 90 days to have at least 26 bits of extra -entropy above the required security level. System that allows only 1 try -every minute on average (to make it better for users it can also allow 5 -tries before the account is locked for 5 minutes) will require only -about 17 bits for password that is used for 90 days. Alternatively the -system may save all unsuccessful logon attempts and lock the account -after 100 attempts to require passwords with around 7 bits of extra -entropy. Note that such system needs the user to change the password -before the account can be unlocked. - -Passwords that are easy to remember for users are passwords that don't -contain any special characters, numbers or upper case letters. In other -words, are passphrases that are comprised just of regular words. - -One way to look at security of a, e.g. 4 word, passphrase is to think of -the words as symbols chosed from very large alphabet. Entropy estimate -then is calculated in the same way as for smaller alphabet. For words -chosen from a list of 1024 words, the entropy per word will be 10 bits -and for whole 4 word passphrase the entropy will be 40 bits. While the -english language, as well as most other languages, use much more than -1024 words in everyday conversations, humans don't select words -uniformely from this set and multiple studies have shown that words -selected for passwords have 10 bits of entropy at most. - -So, to aid users in selecting uniformely random passwords with high -entropy, is to generate multi-word passphrases for them. For example, by -proposing such passwords during account creation. - -https://xkcd.com/936/ - -Unfortunately, passwords with anough entropy to remain secure against -any kind of attack (having the same level of security as AES-128) would -be too hard to remember for average user. That's why it is recommended -that you augment your authentication system with a second factor. - -Password Alternatives ---------------------- - -Cryptographic logon is a much better alternative to using passwords. Not -only is the complexity higher than that of a simple password or phrase -but the key or key-based-token used is, in theory, completely random. -Using cryptographic keys to authenticate a user means the user doesn't -have to remember anything which should reduce the number of -authentication problems. This method of authentication is also only -single factor (something you have). This has similar weaknesses to the -password-only approach as anyone gaining access to the key or token can -authenticate to the system. - -The better way to provide a more-secure authentication system is to -combine the password and cryptographic solutions. Using a multi-factor -approach raises the bar needed to gain access to a system. Now an -attacker must have knowledge of both the password and the cryptographic -key. While not impossible, this does raise the bar for breaking in to a -system. - -Password storage for validation -------------------------------- - -To authenticate to a system some knowledge of the password is needed on -the server side. This can either be the plaintext password, encrypted -password, or a cryptographic hash of the password. Storing passwords as -plaintext or encrypted is dangerous as an attacker that gains access to -a system's password file can easily read the plaintext passwords or -decypher the passwords. - -The proper, most-secure method of storing authentication information is -using cryptographic hashes of passwords. Because it is generally not -possible to reverse a hash to determine the actual passphrase, using -hashes allows the server to verify a password without the password being -stored in the clear. A properly salted and stretched hash is very secure -against attacks even when the attacker has the access to hash itself. - -Salt -~~~~ - -A salt is a randomly generated string of characters that are -concatenated and processed with the hash function. The result helps -defend against dictionary and rainbow table attacks. Good salt should be -globally unique (so that precomputing the hash values is useful only for -one account). The easiest way to achieve that is to use large, -cryptographically secure random number, 128 bit (16 byte) value should -guarantee that for the forseeable future. - -Stretching -~~~~~~~~~~ - -The other important factor in password verification is how long it takes -to check if a given password matches given hash. If this operation takes -just few hundred CPU cycles, the attacker can check tens of thousands of -passwords every second. On the other hand, this is not an operation that -needs to be this fast for users, established sessions usually are active -for minutes if not hours. To make it take longer, the same hash -algorithm is applied multiple times over and over again. Standard -password stretching algorithms include PBKDF2, bcrypt and scrypt. The -rule of thumb is that checking if the password matches given hash should -take around 100ms on fastest server used in online system (like a -website or kerberos key server) and 1s for offline data storage (like -disk encryption, private key storage or password managers). Using -stretching on an online system that uses login rate limiting is also -important as part of defense in depth and to limit damage of password -database leak in case of password reuse. - -Hash Algorithms -~~~~~~~~~~~~~~~ - -The hash algorithm is just as important as the other implementations of -the authentication system. Many old hashes get cracked and can be -calculated much more quickly now than in the past, even if we exclude -the fact that current computers are much faster. The hashing of -passwords is like an arms race, as computers become faster, hashes need -to become more complex to prevent simple cracking. - -Password storage for use ------------------------- - -Using passwords or keys on servers for authenticating to other servers -or services means that credentials are stored in the clear. While using -authentication tokens (passwords or keys) between servers is important -they are at risk to being obtained if access is ever gained to the -server. While it's almost impossible to completely protect the -credentials it's important to protect them to the maximum extent -possible. - -Credentials should have proper restricting owner and group permissions -and should not be world-readable. To prevent accidental credential -changes (or a DoS attack), the credentials should be read-only. - -If credentials are ever stored in a database, they should be encrypted -using a key stored somewhere on the filesystem. While this won't prevent -an attack where the attacker has local access, it will prevent the -attack were the database is dumped. - -Account Verification --------------------- - -Account verification is necessary to (1) provide some assurance that the -user is who he or she claims and (2) provide a way to verify or notify -the user when certain actions occur, such as changes to their user -information or password. - -Most websites implement one of two different verification methodologies: -external verification channels or security questions. Unless absolutely -necessary, verification should be performed using external verification -channels. - -External Verification Channel -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -One crucial component of any user account is the user must be verifiable -externally to the service providing the account. That is, there must be -a way to contact or confirm that the user is who they say and verify -certain sensitive activities, including account creation and password -changes. Typically this is an e-mail address, but can be a mobile phone -or other medium capable of receiving a unique link or access code. - -Accounts must be associated with at least one external verification -channel, but more may be supported. It is recommended that each external -verification channel be bound to only one account. - -Security Questions -~~~~~~~~~~~~~~~~~~ - -Another commonly used method is using ''security questions'', though -this approach is generally frowned upon by the security community -http://www.theatlantic.com/technology/archive/2012/08/security-questions-the-biggest-joke-in-online-identity-verification/260835/[1], -https://www.schneier.com/essay-081.html[2]. - -There are several factors to consider when designing security questions -http://www.quora.com/Security/Why-do-banks-insist-on-using-mothers-maiden-name-as-a-security-question[3]: -Relevant:: The question should be applicable to a majority of your -users. Asking a user for the name of their first grade teacher may not -be applicable for international users as they might not be familiar with -the concept of "first grade"., Absolute:: Every question should have -exactly one correct answer. For example, questions that ask for "What is -your favourite..." should not be used as personal preferences may change -with time., Rememberable:: Users should be able to easily recall the -answer when prompted with the question. For example, asking the user -"what was the last thing you ate?" is only temporarily relevant and will -likely not be correctly recalled months into the future., Private:: The -answer should be known only by the user and hard to find through -internet searches or research of publicly available information. -Questions that ask for your mother's maiden name or place of birth are -not safe as the answers are all publicly available. Instead of creating -a list of security questions, another option is to allow the user to -provide their own questions and answers. The upside here is that the -users can identify the questions and answers that best reflect them and -relieves the developer from having to create good security questions. -However, users are likely to create very insecure questions with trivial -answers. In such case, the questions become the wekest link and are most -likely to be exploited by attackers. - -Password Processes ------------------- - -These are recommended processes for handling common user authentication -activities. They all assume support for account verification via -external verification channels. - -New User Registration -~~~~~~~~~~~~~~~~~~~~~ - -\1. Collect: Collect user information: User ID, Verification method -(e-mail, text message, phone call, etc.), Contact information, -Authentication credentials (password, OpenID, etc.) - -\2. Confirm: Contact user through verification channel Send randomized -verification token with timeout, Require the user to acknowledge (e.g., -Click on link, Input PIN) - -\3. Create: Create the account and notify the user User authentication -can be collected either during the initial collection phase or after -account verification. - -Forgotten Login -~~~~~~~~~~~~~~~ - -\1. Collect: Request user to enter in information for registered -external verification channel - -\2. Validate: Check that the provided information matches a user account - -\3. Notify: Transmit the user login identifier in a message on the -registered channel - -Forgotten Password -~~~~~~~~~~~~~~~~~~ - -\1. Collect: Request user to enter their user identifier - -\2. Validate: Check that the user ID matches a valid user account - -\3. Confirm: Contact user through external verification channel Send -randomized verification token with timeout, Require the user to -acknowledge (e.g., E-mail with tokenized password reset link; Message -with PIN that needs to be provided to reset password) - -\4. Request: Require that the user provide a new password - -\5. Validate: Require the user to re-enter the new password. Use CSRF -prevention techniques such as randomized response tokens to ensure this -change is being initiated by the user. - -\6. Notify: Send a notification to the user stating that their account -password has been changed - -There should never be a copy of the password (plaintext or encrypted) -associated with the account. It should be '''impossible''' for the -service to provide the user with a plaintext copy of their current -password! - -Password Change -~~~~~~~~~~~~~~~ - -\1. Authenticate: The user must be logged into the account - -\2. Request: Require the user to enter their current password and new -password - -\3. Validate: Require the user to re-enter the new password. Use CSRF -prevention techniques such as randomized response tokens to ensure this -change is being initiated by the user. - -\4. Notify: Send a notification to the user stating that their account -password has been changed - -Accepting login credentials ---------------------------- - -Just as important as setting up the credentials is the means of -accepting them. If certain precautions aren't taken an account can be -compromised no matter how secure the used password is. Here are some -things to think about: _Use encrypted and authenticated paths._ - When -authentication credentials are sent across a network (intranet or -Internet) it's important to use an encrypted and authenticated path. -This not only prevents exposure of the credentials to anyone monitoring -the network but also authenticates the server being used for -authentication of the user as to prevent a MITM attack., _Never trust -your network_You should never trust your network to be free from -intruders. The past is filled with many cases where developers thought -the network could be trusted, but had indeed been compromised., _Use -authentication methods that don't leave traces._ - Credentials shouldn't -be left behind on the client after authenticating. It would be trivial -to look back at browser history or bash history to return usernames and -passwords. Always use interactive mechanisms and never accept passwords -in URLs or in CLI command arguments. - -Moving beyond the password --------------------------- - -A few years ago there were several expensive, proprietary token services -available that would allow you to use a multi-factor authentication -solution. These solutions were seen as blackbox solutions but were from -"trusted" companies. Unfortunately we now know that at least some of -those solutions were broken accidentally or intentionally making -reliance on these solutions problematic at best. - -Fortunately for us, today there are several open source solutions -including the Yubikey and the Google Authenticator. Both provide an easy -and low-cost solution to providing a second factor for authentication. - -sudo, better than root ----------------------- - -Beginning with the release of RHEL7, system administrators are now -allowed to setup users with administrative access at installation time. -GNOME3 also allows administrator priviledges to be added to users via -the user account management GUI. Both of these solutions are simply -adding the user to the wheel group, thus giving them sudo access to the -system. Using the old-fashioned way of manually adding someone to the -wheel group still works and provides the same outcome. - -So why is it better to use sudo instead of allowing users to have root -access? There are several reasons why sudo is more beneficial: -Accountability (audit trail) - sudo commands are logged and you'll know -who is doing what and when., Ease of removing access - sudo access means -that you don't have a bunch of people running around with the keys to -the castle. If someone no longer needs administrator access to the -system simply removing their account from the wheel group is much easier -than resetting the root password and letting everyone else know the new -password., Simplicity for users - No longer will users have to remember -or use their cheat sheet to login as the root user., Auditability - With -wheel access it's easy to see who has access instead of assuming that no -one outside of your administrative group has received a copy of the root -credentials. diff --git a/index.adoc b/index.adoc new file mode 100644 index 0000000..2ed0610 --- /dev/null +++ b/index.adoc @@ -0,0 +1,428 @@ +Password Strength +----------------- + +Password authentication is the weakest authentication method available. +Unfortunately it is also the most prevalent and deceptively implement. +Password authentication only requires a single factor (something you +know) which in can be guessed by an attacker. Because of that, any +system that uses only password authentication needs to take multiple +issues into account to be secure. + +Because this authentication method is inherently weak it is important to +require high strength passwords (or change them often). + +Password entropy +~~~~~~~~~~~~~~~~ + +Password strength can be expressed as the amount of entropy present in +it. The easiest way to understand entropy in the context of passwords is +to think of it as "how easy it is to guess the password". Password that +is selected uniformly (that is, every value has the same chance of +getting picked) from a set of passwords that contain "1", "2", "3" and +"4" will have a probability of 1/4 = 0.25 of being chosen. Or to express +it in way that's similar to other values in cryptography, has 2 bits of +entropy (because -log2(-0.25) = 2 ). For longer passwords, it's easier +to just count the number of possibiltities and calculate the base 2 +logarithm to know its entropy. For example, passwords picked uniformely +from a set of all 8 character permutations of lower case letters will be +picked from a set of 26 * 26 * 26 * 26 * 26 * 26 = 26^6 = 308915776 +possible passwords. That means, that every such password will have +around log2(26^6) = 28.2 bits of entropy. + +Note that a password that is not picked uniformely (like is nearly +always the case with user chosen passwords) will have much more complex +entropy estimation. Let's change the previous example so that the +password "1" is chosen by half the users, and all the other passwords +are selected uniformely. That means the probabilities of the passwords +are "1" = 1/2, "2" = 1/6, "3" = 1/6 and "4" = 1/6. Alternatively, the +passwords have the following entropy estimates: "1" = 1 bit, "2" = 2.59 +bit, "3" = 2.59 bit and "4" = 2.59 bit. That's why a password that +consists of 8 lower case characters not necessairly has around +log2(26^8)=37.6 bits of entropy. + +Password guessability +~~~~~~~~~~~~~~~~~~~~~ + +Let's consider a system that only allows passwords that are single lower +case letter and the passwords are chosen uniformely by users. Your +chance that you won't guess such password in one try is 25 to 26 (which +is about 96%). But if you are given two tries to guess the password, +your chances of not guessing it are equal to 25/26 * 24/25 = 24/26 +(because to fail you have to fail guessing it the first time and fail +the second time, knowing already which password is wrong) or about 92%. +For three guesses, the chance of not guessing the correct letter in 3 +tries is 25/26 * 24/25 * 23/24 = 23/26 which is about 88.5%. In general, +for such password, given n tries, the probability you won't guess the +number is (26-n)/26. Now, if you want to know the probability that you +will guess the password in either first, second, third or n-th try, you +just need to substract the previous number from one: 1 - (26/n)/26 = +n/26. We can use this number in the same way as with the single guessing +case to calculate the level of security provided by the password when +the attacker is given n-tries to guess it: -log2(n/26). So, while +password in this system has about -log2(1/26)=log2(26)=4.7 bits of +entropy, a system that allows 4 tries before the password needs to be +changed has effective strength of about -log2(4/26) = 2.7 bits. In case +we have calculated the entropy of the password (in this case 4.7 bits) +and know the amount of tries the attacker can perform expressed in bits +(in this case log2(4)=2 bits), the calculation is a simple case of +subtraction: 4.7-2=2.7 bits. + +In general, a password with n bits of entropy on a system that allows m +login attempts before the account is locked provides n-log2(m) bits of +security. + +Alternative way to think about security of passwords is how likely it is +that the password will remain safe during its lifetime. A password with +10 bits of security in a given system has a chance of about 99.9% to not +be guessed. Password with 14 bits of security has a chance of about +99.99% to remain safe during its lifetime and so on. + +Practical recommendation +~~~~~~~~~~~~~~~~~~~~~~~~ + +There are two main ways to get a system in which the password is +unlikely to be guessed by attacker: use passwords that are simple (have +low entropy) but are changed often or use very complex passwords (that +have high entropy) and use them for long time. Optimal system should +detect which kind of password user selected and force user to change it +often enough to preserve security of system. + +While it is easy to say to require the users to pick passwords +uniformely ("really at random") from all 8 or 10 character permutations +of lower and upper case letters, digits and special characters to get +passwords that met chosen level of security it doesn't take the human +aspect of using such system into account. + +To aid users in selecting secure passwords the system can do two things, +limit how effective the attacker can be and to provide feedback of how +secure the password is and refuse use passwords with little entropy. + +Limiting the effectiveness of attacker should be done by two ways: by +limiting the rate at which the server itself can check the correctness +of the password (by hash stretching) and by limiting the rate or amount +of tries the attacker is given to guess the passwords. System which +allows testing if a guess is correct every 100ms will require for a +password that is used for 90 days to have at least 26 bits of extra +entropy above the required security level. System that allows only 1 try +every minute on average (to make it better for users it can also allow 5 +tries before the account is locked for 5 minutes) will require only +about 17 bits for password that is used for 90 days. Alternatively the +system may save all unsuccessful logon attempts and lock the account +after 100 attempts to require passwords with around 7 bits of extra +entropy. Note that such system needs the user to change the password +before the account can be unlocked. + +Passwords that are easy to remember for users are passwords that don't +contain any special characters, numbers or upper case letters. In other +words, are passphrases that are comprised just of regular words. + +One way to look at security of a, e.g. 4 word, passphrase is to think of +the words as symbols chosed from very large alphabet. Entropy estimate +then is calculated in the same way as for smaller alphabet. For words +chosen from a list of 1024 words, the entropy per word will be 10 bits +and for whole 4 word passphrase the entropy will be 40 bits. While the +english language, as well as most other languages, use much more than +1024 words in everyday conversations, humans don't select words +uniformely from this set and multiple studies have shown that words +selected for passwords have 10 bits of entropy at most. + +So, to aid users in selecting uniformely random passwords with high +entropy, is to generate multi-word passphrases for them. For example, by +proposing such passwords during account creation. + +https://xkcd.com/936/ + +Unfortunately, passwords with anough entropy to remain secure against +any kind of attack (having the same level of security as AES-128) would +be too hard to remember for average user. That's why it is recommended +that you augment your authentication system with a second factor. + +Password Alternatives +--------------------- + +Cryptographic logon is a much better alternative to using passwords. Not +only is the complexity higher than that of a simple password or phrase +but the key or key-based-token used is, in theory, completely random. +Using cryptographic keys to authenticate a user means the user doesn't +have to remember anything which should reduce the number of +authentication problems. This method of authentication is also only +single factor (something you have). This has similar weaknesses to the +password-only approach as anyone gaining access to the key or token can +authenticate to the system. + +The better way to provide a more-secure authentication system is to +combine the password and cryptographic solutions. Using a multi-factor +approach raises the bar needed to gain access to a system. Now an +attacker must have knowledge of both the password and the cryptographic +key. While not impossible, this does raise the bar for breaking in to a +system. + +Password storage for validation +------------------------------- + +To authenticate to a system some knowledge of the password is needed on +the server side. This can either be the plaintext password, encrypted +password, or a cryptographic hash of the password. Storing passwords as +plaintext or encrypted is dangerous as an attacker that gains access to +a system's password file can easily read the plaintext passwords or +decypher the passwords. + +The proper, most-secure method of storing authentication information is +using cryptographic hashes of passwords. Because it is generally not +possible to reverse a hash to determine the actual passphrase, using +hashes allows the server to verify a password without the password being +stored in the clear. A properly salted and stretched hash is very secure +against attacks even when the attacker has the access to hash itself. + +Salt +~~~~ + +A salt is a randomly generated string of characters that are +concatenated and processed with the hash function. The result helps +defend against dictionary and rainbow table attacks. Good salt should be +globally unique (so that precomputing the hash values is useful only for +one account). The easiest way to achieve that is to use large, +cryptographically secure random number, 128 bit (16 byte) value should +guarantee that for the forseeable future. + +Stretching +~~~~~~~~~~ + +The other important factor in password verification is how long it takes +to check if a given password matches given hash. If this operation takes +just few hundred CPU cycles, the attacker can check tens of thousands of +passwords every second. On the other hand, this is not an operation that +needs to be this fast for users, established sessions usually are active +for minutes if not hours. To make it take longer, the same hash +algorithm is applied multiple times over and over again. Standard +password stretching algorithms include PBKDF2, bcrypt and scrypt. The +rule of thumb is that checking if the password matches given hash should +take around 100ms on fastest server used in online system (like a +website or kerberos key server) and 1s for offline data storage (like +disk encryption, private key storage or password managers). Using +stretching on an online system that uses login rate limiting is also +important as part of defense in depth and to limit damage of password +database leak in case of password reuse. + +Hash Algorithms +~~~~~~~~~~~~~~~ + +The hash algorithm is just as important as the other implementations of +the authentication system. Many old hashes get cracked and can be +calculated much more quickly now than in the past, even if we exclude +the fact that current computers are much faster. The hashing of +passwords is like an arms race, as computers become faster, hashes need +to become more complex to prevent simple cracking. + +Password storage for use +------------------------ + +Using passwords or keys on servers for authenticating to other servers +or services means that credentials are stored in the clear. While using +authentication tokens (passwords or keys) between servers is important +they are at risk to being obtained if access is ever gained to the +server. While it's almost impossible to completely protect the +credentials it's important to protect them to the maximum extent +possible. + +Credentials should have proper restricting owner and group permissions +and should not be world-readable. To prevent accidental credential +changes (or a DoS attack), the credentials should be read-only. + +If credentials are ever stored in a database, they should be encrypted +using a key stored somewhere on the filesystem. While this won't prevent +an attack where the attacker has local access, it will prevent the +attack were the database is dumped. + +Account Verification +-------------------- + +Account verification is necessary to (1) provide some assurance that the +user is who he or she claims and (2) provide a way to verify or notify +the user when certain actions occur, such as changes to their user +information or password. + +Most websites implement one of two different verification methodologies: +external verification channels or security questions. Unless absolutely +necessary, verification should be performed using external verification +channels. + +External Verification Channel +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +One crucial component of any user account is the user must be verifiable +externally to the service providing the account. That is, there must be +a way to contact or confirm that the user is who they say and verify +certain sensitive activities, including account creation and password +changes. Typically this is an e-mail address, but can be a mobile phone +or other medium capable of receiving a unique link or access code. + +Accounts must be associated with at least one external verification +channel, but more may be supported. It is recommended that each external +verification channel be bound to only one account. + +Security Questions +~~~~~~~~~~~~~~~~~~ + +Another commonly used method is using ''security questions'', though +this approach is generally frowned upon by the security community +http://www.theatlantic.com/technology/archive/2012/08/security-questions-the-biggest-joke-in-online-identity-verification/260835/[1], +https://www.schneier.com/essay-081.html[2]. + +There are several factors to consider when designing security questions +http://www.quora.com/Security/Why-do-banks-insist-on-using-mothers-maiden-name-as-a-security-question[3]: +Relevant:: The question should be applicable to a majority of your +users. Asking a user for the name of their first grade teacher may not +be applicable for international users as they might not be familiar with +the concept of "first grade"., Absolute:: Every question should have +exactly one correct answer. For example, questions that ask for "What is +your favourite..." should not be used as personal preferences may change +with time., Rememberable:: Users should be able to easily recall the +answer when prompted with the question. For example, asking the user +"what was the last thing you ate?" is only temporarily relevant and will +likely not be correctly recalled months into the future., Private:: The +answer should be known only by the user and hard to find through +internet searches or research of publicly available information. +Questions that ask for your mother's maiden name or place of birth are +not safe as the answers are all publicly available. Instead of creating +a list of security questions, another option is to allow the user to +provide their own questions and answers. The upside here is that the +users can identify the questions and answers that best reflect them and +relieves the developer from having to create good security questions. +However, users are likely to create very insecure questions with trivial +answers. In such case, the questions become the wekest link and are most +likely to be exploited by attackers. + +Password Processes +------------------ + +These are recommended processes for handling common user authentication +activities. They all assume support for account verification via +external verification channels. + +New User Registration +~~~~~~~~~~~~~~~~~~~~~ + +\1. Collect: Collect user information: User ID, Verification method +(e-mail, text message, phone call, etc.), Contact information, +Authentication credentials (password, OpenID, etc.) + +\2. Confirm: Contact user through verification channel Send randomized +verification token with timeout, Require the user to acknowledge (e.g., +Click on link, Input PIN) + +\3. Create: Create the account and notify the user User authentication +can be collected either during the initial collection phase or after +account verification. + +Forgotten Login +~~~~~~~~~~~~~~~ + +\1. Collect: Request user to enter in information for registered +external verification channel + +\2. Validate: Check that the provided information matches a user account + +\3. Notify: Transmit the user login identifier in a message on the +registered channel + +Forgotten Password +~~~~~~~~~~~~~~~~~~ + +\1. Collect: Request user to enter their user identifier + +\2. Validate: Check that the user ID matches a valid user account + +\3. Confirm: Contact user through external verification channel Send +randomized verification token with timeout, Require the user to +acknowledge (e.g., E-mail with tokenized password reset link; Message +with PIN that needs to be provided to reset password) + +\4. Request: Require that the user provide a new password + +\5. Validate: Require the user to re-enter the new password. Use CSRF +prevention techniques such as randomized response tokens to ensure this +change is being initiated by the user. + +\6. Notify: Send a notification to the user stating that their account +password has been changed + +There should never be a copy of the password (plaintext or encrypted) +associated with the account. It should be '''impossible''' for the +service to provide the user with a plaintext copy of their current +password! + +Password Change +~~~~~~~~~~~~~~~ + +\1. Authenticate: The user must be logged into the account + +\2. Request: Require the user to enter their current password and new +password + +\3. Validate: Require the user to re-enter the new password. Use CSRF +prevention techniques such as randomized response tokens to ensure this +change is being initiated by the user. + +\4. Notify: Send a notification to the user stating that their account +password has been changed + +Accepting login credentials +--------------------------- + +Just as important as setting up the credentials is the means of +accepting them. If certain precautions aren't taken an account can be +compromised no matter how secure the used password is. Here are some +things to think about: _Use encrypted and authenticated paths._ - When +authentication credentials are sent across a network (intranet or +Internet) it's important to use an encrypted and authenticated path. +This not only prevents exposure of the credentials to anyone monitoring +the network but also authenticates the server being used for +authentication of the user as to prevent a MITM attack., _Never trust +your network_You should never trust your network to be free from +intruders. The past is filled with many cases where developers thought +the network could be trusted, but had indeed been compromised., _Use +authentication methods that don't leave traces._ - Credentials shouldn't +be left behind on the client after authenticating. It would be trivial +to look back at browser history or bash history to return usernames and +passwords. Always use interactive mechanisms and never accept passwords +in URLs or in CLI command arguments. + +Moving beyond the password +-------------------------- + +A few years ago there were several expensive, proprietary token services +available that would allow you to use a multi-factor authentication +solution. These solutions were seen as blackbox solutions but were from +"trusted" companies. Unfortunately we now know that at least some of +those solutions were broken accidentally or intentionally making +reliance on these solutions problematic at best. + +Fortunately for us, today there are several open source solutions +including the Yubikey and the Google Authenticator. Both provide an easy +and low-cost solution to providing a second factor for authentication. + +sudo, better than root +---------------------- + +Beginning with the release of RHEL7, system administrators are now +allowed to setup users with administrative access at installation time. +GNOME3 also allows administrator priviledges to be added to users via +the user account management GUI. Both of these solutions are simply +adding the user to the wheel group, thus giving them sudo access to the +system. Using the old-fashioned way of manually adding someone to the +wheel group still works and provides the same outcome. + +So why is it better to use sudo instead of allowing users to have root +access? There are several reasons why sudo is more beneficial: +Accountability (audit trail) - sudo commands are logged and you'll know +who is doing what and when., Ease of removing access - sudo access means +that you don't have a bunch of people running around with the keys to +the castle. If someone no longer needs administrator access to the +system simply removing their account from the wheel group is much easier +than resetting the root password and letting everyone else know the new +password., Simplicity for users - No longer will users have to remember +or use their cheat sheet to login as the root user., Auditability - With +wheel access it's easy to see who has access instead of assuming that no +one outside of your administrative group has received a copy of the root +credentials.