Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Best practices to Secure your Website - Page 2
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Best practices to Secure your Website

2

Comments

  • @joepie91 said: which is an insecure algorithm in the sense that it will silently cut off passwords longer than 50 characters

    How does that make it insecure? A 59-60 characters long password is sufficient secure.

    Thanked by 1Nexus
  • bcrypt cutting off long passwords isn't a weakness of bcrypt. It's simply not designed for longer passwords. You don't increase the cryptographic strength by increasing the password length, you increase it by increasing the number of iterations.

    Thanked by 1Nexus
  • joepie91joepie91 Member, Patron Provider
    edited October 2012

    @gsrdgrdghd said: How does that make it insecure? A 59-60 characters long password is sufficient secure.

    Bullshit. There are plenty of people that use phrases instead of passwords for authentication - in their case it may not be enough. That you personally find 60 characters enough does not mean that this goes for everyone else. You have to keep in mind that you're not developing a site for yourself, but for other users.

    @NickM said: bcrypt cutting off long passwords isn't a weakness of bcrypt.

    Um, yes, it is. If you're not aware of the character limit, [you will be caught by surprise by PHP (and everything else) silently cutting off your password, thereby reducing the strength of the password to the max amount of characters(http://pastebin.com/2Kyh8VXn), regardless of the actual password strength - this may lead to making bad decisions in terms of whether a passphrase is sufficient or not.

    If you are aware of the character limit, you are potentially forcing your users to choose less secure passwords, which is a weakness in itself.

    Why are you guys making such an effort to 'defend' bcrypt when it has a clear demonstrable security issue, while offering no unique features that I am aware of?

    Instead of putting that effort into trying to find justification for using bcrypt, put it into using a sane hashing algorithm. Scrypt, SHA512, I don't care - as long as it isn't an algorithm with a known (and practically undocumented!) vulnerability. You're promoting poor security practice.

    @NickM said: You don't increase the cryptographic strength by increasing the password length, you increase it by increasing the number of iterations.

    Uh, what? You realize that password length does have a significant impact on the strength of a hash, right?

    Thanked by 1Nexus
  • @joepie91 from password breaches it's clear the majority use weak passwords - often very short. This obviously doesn't make it good/right but that is the reality. Whilst I can agree there are peeps that do use very long passwords/phrases this is a tiny, tiny minority. A discussion about webappsec that digresses into supporting 60+ len passwords is missing the wood for the trees...bigger fish to fry, no?

    Thanked by 1Nexus
  • @joepie91 said: hat you personally find 60 characters enough does not mean that this goes for everyone else.

    Please learn your math. There is no practical benefit of using a password with 70 characters instead of one with 60 characters.

    Thanked by 1Nexus
  • @fresher_06 said: Guys . I have the below basic PHP login script which I am using on my main website for the customers to log in ..Please let me know the potential threats in this script and any kind of loophole,which you feel ..any kind of suggestion will be highly appreciable ..

    Here is the script --
    http://pastebin.com/TtbBmKvJ

    Apart from other issues mentioned above, It is a bad idea to let the user know if password was wrong or the email(userId) was wrong after a login failure. You should print out the same failure message for both.

  • @joepie91 said: @gsrdgrdghd said: How does that make it insecure? A 59-60 characters long password is sufficient secure.

    Bullshit. There are plenty of people that use phrases instead of passwords for authentication - in their case it may not be enough. That you personally find 60 characters enough does not mean that this goes for everyone else. You have to keep in mind that you're not developing a site for yourself, but for other users.

    Most of the time I'm using > 128 character passwords from keepass, dunno about youguys. If a site can't handle that I move away, but if I have to use it I send a mail to the owners. Pagerduty.com first had a 40 character limit, mailed them, now they allow my 256 char password.

  • @gsrdgrdghd said: Please learn your math. There is no practical benefit of using a password with 70 characters instead of one with 60 characters.

    Crap. Every character added to a passwords increases the brute force time exponentially. (As long as the algorithm or implementation is not cracked). There is a big difference between a 60 or 70 char password.

  • happelhappel Member
    edited October 2012

    True, but the practical benefit is 0. Does it really matter if an attacker needs 10 years vs 15 years to bruteforce your password? I don't think so :-).

  • joepie91joepie91 Member, Patron Provider

    @craigb said: @joepie91 from password breaches it's clear the majority use weak passwords - often very short. This obviously doesn't make it good/right but that is the reality. Whilst I can agree there are peeps that do use very long passwords/phrases this is a tiny, tiny minority. A discussion about webappsec that digresses into supporting 60+ len passwords is missing the wood for the trees...bigger fish to fry, no?

    That would be valid reasoning only if their character limit added more security in another respect - which I am not aware of it doing.

    @gsrdgrdghd said: Please learn your math. There is no practical benefit of using a password with 70 characters instead of one with 60 characters.

    I've said this on IRC towards NickM and I'll say it again here:

    <joepie91> if you do not understand the concept of words being characters in a passphrase, you have no business making decisions about cryptographical strength

    @divya said: Apart from other issues mentioned above, It is a bad idea to let the user know if password was wrong or the email(userId) was wrong after a login failure. You should print out the same failure message for both.

    This is not something I'd necessarily agree with - not telling the user what the problem is, barely adds any security (after all, you should already have bruteforce protections in place anyway), and creates a very big problem for users. More about this here: http://blog.mailchimp.com/social-login-buttons-arent-worth-it/

    @happel said: True, but the practical benefit is 0. Does it really matter if an attacker needs 10 years vs 15 years to bruteforce your password? I don't think so :-).

    Actually, it does. Your response seems to assume that cryptographical algorithms will always retain the same strength and tak e the same time to be bruteforced - but that isn't the case. Computing equipment gets stronger over time, and algorithms get cracked. The advantage may not exist right now, but it damn well will when the algorithm of choice suddenly gets broken. And especially if the site you are signing up to still uses MD5 hashes (and sadly, many do), you'll want to have something that at least takes a bit of time to crack. Which makes me think of the following joke:

    Two guys are in the jungle when they see a lion running towards them. Frantically, one of the men starts putting on his running shoes.

    Surprised, the other man says " What are you thinking, you can't outrun a lion!!!"

    " I don't have to outrun the lion," said the man, " I just have to outrun you."

  • @joepie91 said: This is not something I'd necessarily agree with - not telling the user what the problem is, barely adds any security (after all, you should already have bruteforce protections in place anyway), and creates a very big problem for users. More about this here: http://blog.mailchimp.com/social-login-buttons-arent-worth-it/

    I agree with the article on reduction of login failures due to ease of guessing/recollecting your own password. At the same time, you make it much easier for an acquaintance to guess and identify your userid/password with the mentioned approach.
    To improve the login experience, I send a welcome message with userId mentioned in it during registration. The mail also contains the email verification/account activation link whenever verified mails ids are needed.
    It's a matter of choice and I have seen very few authentication systems using specific error messages for id and password errors.

  • joepie91joepie91 Member, Patron Provider
    edited October 2012

    @divya said: I agree with the article on reduction of login failures due to ease of guessing/recollecting your own password. At the same time, you make it much easier for an acquaintance to guess and identify your userid/password with the mentioned approach.

    Not really. If you allow more than a certain amount of login attempts without at the very least notifying the user and temporarily blocking someone in the first place (which would make 'hiding' things pointless), you're doing it wrong to start with.

    @divya said: To improve the login experience, I send a welcome message with userId mentioned in it during registration. The mail also contains the email verification/account activation link whenever verified mails ids are needed.

    A lot of people tend to change e-mail addresses and lose access to old e-mails or e-mail addresses. They would have a problem. This isn't a rare situation either.

    @divya said: It's a matter of choice

    No, it's not. You can only call it a 'matter of choice' if there is no significant difference to the user regardless of what you pick. It's matter of user-friendliness versus perceived security.

    @divya said: and I have seen very few authentication systems using specific error messages for id and password errors.

    I've seen many do that. Not that it matters; popularity should not be a factor in security (or user-friendliness, for that matter).

  • @joepie91 True, i didn't consider the people using passphrases. According to some quick research a common 58 characters long passphrase provides only 80 bits of entropy.

    @Raymii there is no practical difference between a completly random alphanumerical 60 characters and 70 characters password.

  • @gsrdgrdghd said: @Raymii there is no practical difference between a completly random alphanumerical 60 characters and 70 characters password.

    completly random does not exist. And in cracking time (brute-force) there is a big difference. However, lets say a thousand years and two-thousand years, still big difference.

  • Now i am displaying the same error message as "Either Email ID or Password is wrong!!"
    for both when Email Id not in the db or the corresponding password is wrong.
    Now the question is how do I use the crypt() function with few thousands of SHA256 rounds
    as mentioned by @joepie91 ..
    Also the script which I mentioned above .. how much it is vulnerable to SQL Injection .
    http://pastebin.com/TtbBmKvJ

  • joepie91joepie91 Member, Patron Provider
    edited October 2012

    @fresher_06 said: Now the question is how do I use the crypt() function with few thousands of SHA256 rounds

    as mentioned by @joepie91 ..

    This is a (modified) snippet from the code that I use

    function CreateHash($input, $dynamic_salt)
    {
        global $settings;
        $hash = crypt($input, "$5\$rounds=50000\${$dynamic_salt}{$settings['salt']}$");
        $parts = explode("$", $hash);
        return $parts[4];
    }
    

    Reasoning for the above: in normal crypt() usage it will output a string that contains not just the hash, but also the salt - and since I use a dynamic (per-user, database-stored) salt plus a static (global, disk-stored) salt, it would be a problem for me to store the static part of the salt in the database. Therefore I generate and store the salt seperately, and just use the hash that is returned from the crypt() function

    Splitting up into a dynamic salt and a static salt is a good idea because it means that someone cannot get the full salt through an SQL injection (or other kind of database access) and would need actual disk access to get the entire salt - which makes cracking a hash harder. This does increase the complexity of your code, and just using a dynamic salt will also be sufficient most of the time.

    The simpler way, only using a dynamic salt:

    /* To create the hash: */
    $salt = random_string(10);
    $hash = crypt($input, "\$5\$rounds=50000\${$salt}\$");
    
    /* To verify the hash: */
    if(crypt($input, $hash) == $hash)
    {
        /* Password was correct! */
    }
    else
    {
        /* Password is invalid. */
    }
    

    You can just store the entire $hash in your database as the hash, and it'll include the salt. Note that the random_string function doesn't actually exist in PHP - it's a custom function I wrote. The code for this is as follows:

    function random_string($length)
    {
        $output = "";
        for ($i = 0; $i < $length; $i++) 
        { 
            $output .= substr("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789", mt_rand(0, 61), 1); 
        }
        return $output;
    }
    

    @fresher_06 said: Also the script which I mentioned above .. how much it is vulnerable to SQL Injection .

    http://pastebin.com/TtbBmKvJ

    It is currently not vulnerable - but to avoid making mistakes in the future, you should still look into using PDO, especially because the mysql_* functions are now officially deprecated and will be removed from PHP in the near future.

    I'd also like to remind you that giving the same error for both an incorrect username and password, doesn't add any proper security - it's a form of security through obscurity, which should be heavily frowned upon. Instead of giving vague errors, add a bruteforce protection, where for example IPs or accounts are temporarily blocked after entering the wrong password 10 times.

    Thanked by 2craigb fresher_06
  • I suggest you read this: http://phpacademy.org/forum/viewtopic.php?f=28&t=15356
    "Thousands of SHA256 rounds" = super bad.

  • Doesn't come back in the article as far as I can see. Please @kamalnasser, tell my why it is "super bad"?

  • joepie91joepie91 Member, Patron Provider

    "Thousands of SHA256 rounds" = super bad.

    That refers to manually doing double hashing, not using the built-in crypt() function which was designed to do this in a proper manner.

  • @joepie91 that's what I meant, didn't read the whole topic here

  • I think something that's been missed here, yet I've seen multiple times:
    Do NOT install random services that you do not need on the web server. For instance, I've seen the following services that are not required on a simple web server:
    8888 - Sun Answerbook HTTP Server.
    27015 - Valve Game Server (wtf)

    Basically, you should cut down the points of entry into the system possible.
    For SSH, do use Private/Public Key instead of password authentication.

    Thanked by 2joepie91 GIANT_CRAB
  • @Boltersdriveer said: 27015 - Valve Game Server (wtf)

    Seems.. legit?

  • @Raymii said: completly random does not exist.

    Of course it does. See quantum RNGs. But even /dev/random produces enough entropy to create a secure password.

    @Raymii said: And in cracking time (brute-force) there is a big difference. However, lets say a thousand years and two-thousand years, still big difference.

    The problem is that we aren't talking about 1000 vs 2000 years. Assume an a-zA-Z0-9 password. That gives 62 possible characters, resulting in 62^60 vs 62^70 possible combinations. A recent computer with a GPU can compute ~5000-1000 bcrypt hashes per second (assuming a reasonable number of rounds).

    Taking into account Moore's law that results in around 163,840,000 guesses per second on a single computer 30 years from now. Lets assume your password is so important 30 years from now that it gets cracked on 6,100 nodes at the same time, which results in 1,000,000,000,000 guesses per second.

    This means that it will take 10^88 years to crack your 60 characters password (or 10^105 for the 70 characters one). As you can see there is no practical difference.

    Thanked by 1Nexus
  • @joepie91 said: I'd also like to remind you that giving the same error for both an incorrect username and password, doesn't add any proper security - it's a form of security through obscurity, which should be heavily frowned upon.

    You have to consider that some developers use email addresses as the username. Is email obscurity frowned upon??

    @gsrdgrdghd said: This means that it will take 10^88 years to crack your 60 characters password (or 10^105 for the 70 characters one). As you can see there is no practical difference.

    If it's getting this technical: Don't you mean it could take up to 10^88 years? I think it's safe to say that most people don't use a password consisting of only 9's.

  • joepie91joepie91 Member, Patron Provider

    @tweakstur said: You have to consider that some developers use email addresses as the username. Is email obscurity frowned upon??

    I don't see how indicating whether an e-mail address exists or not, can be considered a problem in any reasonable situation?

  • @tweakstur said: Don't you mean it could take up to 10^88 years? I think it's safe to say that most people don't use a password consisting of only 9's.

    Of course, i was speaking only in terms of the worst case scenario.

  • @joepie91 said: I don't see how indicating whether an e-mail address exists or not, can be considered a problem in any reasonable situation?

    Email exists = user with that email exists = email is valid and belongs to someone = you'll get an email harvesting bot hammering your login page.

    Thanked by 1djvdorp
  • @joepie91 said: I don't see how indicating whether an e-mail address exists or not, can be considered a problem in any reasonable situation?

    It depends on your application, for example:

    • Try logging into one of your servers through SSH with invalid credentials
    • Try logging into gmail with a wrong password
    • Try logging into your web banking with an invalid account number

    None of them tell you what piece of information is wrong because none of the "usernames" are openly available to the public.

  • joepie91joepie91 Member, Patron Provider

    @vedran said: Email exists = user with that email exists = email is valid and belongs to someone = you'll get an email harvesting bot hammering your login page.

    Yeah, no.

    A login page does not give any more certainty about the validity of an e-mail address than the source where said harvesting bot found the e-mail address in the first place. Trying to find e-mails by bruteforcing a login page is extremely inefficient and generally useless to a spammer.

    @tweakstur said: It depends on your application, for example:

    • Try logging into one of your servers through SSH with invalid credentials
    • Try logging into gmail with a wrong password
    • Try logging into your web banking with an invalid account number

    None of them tell you what piece of information is wrong because none of the "usernames" are openly available to the public.

    That did not actually explain how indicating whether an e-mail address exists or not, is a problem. "They do it too" is not valid reasoning, especially not when talking about security. Instead, come up with solid reasoning.

  • @joepie91 said: That did not actually explain how indicating whether an e-mail address exists or not, is a problem. "They do it too" is not valid reasoning, especially not when talking about security. Instead, come up with solid reasoning.

    Why don't you make the argument for showing valid usernames, emails and account numbers to the public?

    The "Solid Reasoning" behind "They do it too" should be pretty "Self-Explanatory".

Sign In or Register to comment.