#1
  1. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014

    An advanced user authentication system


    Hi,

    this is an attempt to merge current security techniques into a state-of-the-art authentication system. My main source is the OWASP.

    Security is one thing, but the system is also supposed to protect the privacy of all users. This means the e-mail addresses or other private data must not be exposed in any way, neither directly through messages (“This e-mail address does not exist.”) nor indirectly through the behavior of the application.

    Some notes:

    • This is not a tutorial on security basics like preventing SQL injections. If that’s what you’re interested in, you should check E-Oreo's tutorial.
    • This is obviously a work in progress, so it may very well contain errors.
    • Use established solutions whenever you can. If your framework already has a good authentication system, then go with that.




    Requirements

    1. Gaining full control of an account must require one of the following:
      • knowing the password
      • being in control of the e-email account
      • knowing a password reset token

      In other words, it must not be possible to capture an account by, for example, stealing a session or performing a cross-site request forgery.

    2. All passwords and password-equivalents (like password reset tokens) must be safe from being stolen or found out with a brute force attack.

    3. All critical traffic must be resistant to eavesdropping.

    4. Authenticated members must be protected against cross-site request forgery.

    5. The e-mail addresses must not be exposed in any way.

    6. The number of e-mails sent to a single address must be limited in order to prevent e-mail flooding.

    7. All forms must be protected against DOS attacks.




    Approaches

    1. Changing the password or the e-mail address must always be confirmed by entering the current password or clicking on a secret link sent via e-mail.

    2. Brute force protection requires several things:
      • The hash algorithm used for the passwords must be strong. I choose bcrypt, because it's widely accepted as a secure algorithm, and it's already built into PHP. Possible alternatives are the older PBKDF2 or the newer scrypt. However, both are only available through third-party libraries, which can be problematic. Weak algorithms like MD5 or SHA-2 (or home-made combinations) are not an option.
      • To prevent brute force attacks against the front end (i. e. the forms involving the password), the user has to solve a CAPTCHA after a certain number of failed logins. This should slow down the attacks and literally make them more expensive.*
      • All random tokens used for security must be unpredictable and reasonably long. I use the random number generators provided by the OpenSSL or the Mcrypt library (depending on which one is available). Functions like rand(), mt_rand(), uniqid() etc. are not suitable for security purposes, because the results they yield are predictable and also within a relatively small range.


    3. HTTPS must at least be used for all pages involving critical data like the login page and its target. To get actual security, you also need to use HTTPS throughout the whole session. Plain HTTP is not an option, because this allows anybody who is between the user and your server to read and manipulate the communication. They can fetch the password, change the server response to anything they want etc. This would obviously make nonsense of all the other security features.

    4. All forms must include an anti-CSRF token, which is generated once per session.

    5. The form feedback must be carefully designed to not leak any information about the e-mail addresses in the system. This is not trivial. Many websites – including big ones – violate this principle. For example, they'll tell you if you've entered an unregistered address into the password reset form. That's unacceptable. Concrete feedback may only be given by actually sending a mail to this account. It's also important to prevent indirect feedback. For example, if the password is only hashed after a successful lookup of the e-mail address, the response to a valid address will take much longer than the response to an invalid one. This again would allow an attacker to search for registered e-mail addresses.

    6. All public forms generating e-mails (like the registration form or the password reset form) could be abused for e-mail-flooding. While this is not necessarily something a professional attacker would do, kids may very well try it just for fun. To prevent this, only three mails of each kind may be sent to a particular address in 24 hours.

    7. Secure hash algorithms like bcrypt are computationally expensive – they have to be. Attackers can abuse this by sending huge amounts of garbage data instead of the password and let your server hash it. This would overload the server very soon. So it's important to enforce a maximum length for all password and not process overly long input. This maximum should be 72 bytes, because bcrypt will disregard any subsequent bytes anyway. The minimum length should be 6 bytes.







    * Whether or not CAPTCHAs are a good idea is rather controversial. Even the OWASP contradicts itself in this matter: Some articles specifically advice against CAPTCHAs , saying they're ineffictive, user-hostile (which is true) and possibly even illegal. Other articles mention CAPTCHAs as an acceptable technique.

    In any case: What's the alternative? The first OWASP article suggests using temporary lockouts after a certain number of failed logins. But this could easily be abused to completely disable a user account. All an attacker has to do is enter the wrong credentials again and again, blocking the legitimate account owner from logging in. This is not possible with CAPTCHAs. They're annoying as hell, but they don't block you completely.

    So as much as I hate CAPTCHAs myself, I think they're the lesser evil in this case.
    Last edited by Jacques1; June 19th, 2013 at 03:30 PM.
    The 6 worst sins of securityHow to (properly) access a MySQL database with PHP

    Why can’t I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  2. #2
  3. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Registration process

    Risks
    The registration form is a relatively safe place, because obviously it's no direct entry point to existing accounts. However, there are still some risks:
    • If the form tells anybody whether a particular e-mail address is already in use, this violates the privacy of your members. It also makes it easier for an attacker to find active accounts.
    • If the password has no maximum length, this can be abused to do a DOS attack.
    • If the user name can be chosen arbitrarily, attackers might be able to impersonate other members (especially admins!) and gain info through social engineering.
    • The form might be abused to flood an e-mail account with unwanted confirmation mails.


    Security measures
    • The form feedback must not distinguish between unregistered, registered, active or inactive e-mail addresses. There must also be no significant time differences between those cases. The feedback should be given in the e-mail.
    • The password length must be limited.
    • The user names must be unique and easy to distinguish (beware of exotic Unicode characters or similarly looking characters like „I“, „l“ and „1“)
    • The form must adhere to the e-mail limits.
    • Unconfirmed registrations should be deleted after a week in order to avoid storing unnecessary private data.


    Diagram
    Attached Images
    The 6 worst sins of securityHow to (properly) access a MySQL database with PHP

    Why can’t I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  4. #3
  5. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Account Activation

    Nothing special about this: Pass the activation token in the URL and then activate the account. Don't display the e-mail address or include it in the URL.
    The 6 worst sins of securityHow to (properly) access a MySQL database with PHP

    Why can’t I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  6. #4
  7. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Login

    Risks
    • brute force attacks against the password
    • DOS attacks using the password field
    • exposing the existence of particular e-mail addresses


    Security measures
    • The form must display a CAPTCHA in the following two cases: There have been 3 or more subsequent failed login attempts for a particular e-mail address (regardless of whether it exists or not). Or the total number of failed logins has reached a configurable limit.
    • limited password length
    • The form feedback for a failed login attempt must always be the same, regardless of the concrete cause (unregistered address, inactive account, wrong password).


    Diagram
    Attached Images
    The 6 worst sins of securityHow to (properly) access a MySQL database with PHP

    Why can’t I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  8. #5
  9. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Password reset request

    It goes without saying that the password reset form must not actually reset the password. It merely sends a secret token via e-mail, which can then be used to set a new password.

    Don’t forget to hash the reset token! This means you need in fact two random numbers: One as an ID for the reset request, one as a secret.

    Risks
    • exposing the existence of particular e-mail addresses
    • e-mail flooding


    Security measures
    • The form feedback must not tell whether the address is registered, unregistered, active or inactive. This should be done in the e-mail.
    • see e-mail limits


    Diagram
    Attached Images
    The 6 worst sins of securityHow to (properly) access a MySQL database with PHP

    Why can’t I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  10. #6
  11. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Password reset

    Risks
    • An attacker might try to guess the random token. This is hopeless if your random number generator works correctly. But there may be exceptional situations (the generator implementation is buggy, the OS has run out of entropy, the attacker has managed to get a part of the secret token etc.)


    Security measures
    • The form must display a CAPTCHA if the wrong secret has been entered 10 times for a particular token.
    • The form should send an e-mail to the user, saying that the password has been changed. This will provide useful feedback, and it will also give the user the chance to act in case the reset has been done by somebody else.


    Diagram
    Attached Images
    The 6 worst sins of securityHow to (properly) access a MySQL database with PHP

    Why can’t I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  12. #7
  13. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    User settings

    The security risks associated with the user settings are often overlooked. You may think that you need no security at all, since the user is already authenticated. But the “user” may very well be an attacker who has managed to steal the session. There’s also the risk of an attacker abusing a legitimate member as a “proxy” (see cross-site request forgery).

    Risks
    • If you can simply change the e-mail address or password without any confirmation, partial access to an account (gained through stealing a session or performing a CSRF attack) can be used to get full access.
    • brute force attacks against the password
    • DOS attacks using the password field
    • exposing the existence of particular e-mail addresses
    • e-mail flooding


    Security measures
    • Changing the password or-mail address must be confirmed with the current password.
    • If the user has entered a wrong password 10 times in a row, the form must display a CAPTCHA.
    • see password length
    • The form feedback for a failed login attempt must always be the same, regardless of the concrete cause (unregistered address, inactive account, wrong password).
    • see e-mail limits


    Diagram
    Attached Images
    The 6 worst sins of securityHow to (properly) access a MySQL database with PHP

    Why can’t I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  14. #8
  15. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Administration Area

    The administration area is obviously the most important and most threatened component of the system, so you need to take special care protecting it.

    First of all, the administration area must have a separate login mechanism independent from the public login page. Instead of e-mail addresses, it should use randomly generated identifiers (much like API tokens). And of course the password must be strong. This means every administrator has to generate it randomly and store it in a password manager like KeePass.

    It's very important to actually walk new administrators through this procedure and make them aware of their new responsibilities regarding security. I've seen people who had registered with a very weak password (their first name, actually), then got promoted to administrator a few years later and yet continued to use their original password. I'm sure this wouldn't have happened if someone had actually told those administrators to change the password.

    Within the administrator area, all critical actions should be confirmed with the password.

    For additional security, you should also consider using two-factor authentication with TLS client certificates in addition to the passwords.
    The 6 worst sins of securityHow to (properly) access a MySQL database with PHP

    Why can’t I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  16. #9
  17. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Implementation

    (in the works!)
    The 6 worst sins of securityHow to (properly) access a MySQL database with PHP

    Why can’t I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".

IMN logo majestic logo threadwatch logo seochat tools logo