Howdy, Stranger!

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

Sign In with OpenID
Advertise on LowEndTalk.com

In this Discussion

Best practices to Secure your Website

Best practices to Secure your Website

fresher_06fresher_06 Member
edited October 2012 in General

Hi All, Just wanted to check that what all best practices which everybody uses to secure their websites,it can be even as simple as using the mysql_real_escape_string but if we get a check list so that we should not leave any loopholes atleast from our side and our knowledge.However if somebody really targets your website then at least you should have the basic defense.

So please share the common best practices which you generally use to secure your website. ***Please note even if it is about securing the server that would be an addon.

Thanks

Tagged:
Thanked by 1Nexus
«1

Comments

  • Most important in my opinion - key everything up to date.

    Put your small hosting business on auto-pilot with Loading Deck
    Thanked by 1Nexus
  • Seems like we get lots of these types of threads. It would be nice to compile something on the wiki.

    Thanked by 1Nexus
  • Do not try to implement your own SQL injection filters or XSS filters. They will fail. Just run every POST and GET through the appropriate filters mysql_real_escape_string, htmlspecialchars, etc.

    President Of Operations/CEO/CFO/CTO/COO of my account
    image

    Thanked by 2Nexus bnmkl
  • @jhadley said: Most important in my opinion - key everything up to date.

    This. I like to use apticron which sends me an email twice per day for updates which aren't security related (those get installed automagically).

    -CloudFlare to at least deter the nasties. -Use non-default port for SSH -Use key-based authentication for SSH -Disable root login -Dome9 offers pretty cool remote firewall management -Don't allow external connections to MySQL (unless you're using slave/master or some crazy HA setup)

    I also run a lot of WordPress sites so something like InfiniteWP is invaluable for ensuring all of the installs are up to date.

    Thanked by 1Nexus
  • Backups.

    Don't use commonly abused software that attracts every hack in the world (Wordpress and PHP).

    Install as much custom rolled software as you can create. Avoid common PHP admin tools and if you do use them, hide them and limit access heavily based on IP, SSL, etc.

    Bunch of root kit admin tools out there. Scan regularly, just in case.

    Thanked by 1Nexus
    • Look at prepared statements for sql injection.
    • Don't use root as administrative user, only sudo.
    • Key based SSH login
    • Firewall what you don't need open.
    • Don't run your webserver as root
    • Don't run your webserver as root
    Thanked by 2Nexus ajit
  • @pubcrawler said: Install as much custom rolled software as you can create.

    That is very bad advice and will much more likely lead to being hacked than using software that has been reviewed by hundreds of people.

    President Of Operations/CEO/CFO/CTO/COO of my account
    image

  • @pubcrawler Let me know when you find an exploit for phpbb :)

    D4jsp - Where virgins roam free
  • @gsrdgrdghd,

    @pubcrawler said: Install as much custom rolled software as you can create.>

    Depends on who is developing and what their knowledge base is plus their best practices.

    I've never had a compromised anything since we went Linux only 3-4 years back. That was until Wordpress entered our environment.

    Peer review is great. Nerdware is great. Problem is, the most popular platforms and most popular software everyone clings to usually are the most compromised. More updates for security issues than features and bound to get worse.

    So, if you want to secure your website you have a bunch of layers. The OS, the network, the middleware, the database and finally the public facing applications. Seek out specific docs for each of those layers with the term hardening.

    Thanked by 1Nexus
  • @pubcrawler Let me know when you find an exploit for phpbb :) >

    I don't specialize in hacks and exploits. That phase of my life was way more than a decade ago.

    Plenty of phpbb hacks out there or at least have been in the past from a cursory search.

    Thanked by 1Nexus
  • gsrdgrdghdgsrdgrdghd Member
    edited October 2012

    How many severe security bugs have been found in the Wordpress core? Or in the Joomla core?

    President Of Operations/CEO/CFO/CTO/COO of my account
    image

    Thanked by 1Nexus
  • NexusNexus Member
    edited October 2012

    You do have a point, creating custom software / web apps are nice. But there is a fine line where people try to re-invent the wheel as in compared to just downloading a free GPL app.

    @pubcrawler said: Install as much custom rolled software as you can create. Avoid common PHP admin tools and if you do use them

    Do you mean avoid tools like SQL Buddy / phpmyadmin? We would have to create our own for that? :( That's where I personally cross the line and say hell with it. (SQL Buddy is amazing btw)

    D4jsp - Where virgins roam free
  • @gsrdgrdghd,

    The problem with Wordpress may or may not be the core. It tends to be loaded up with plugins and users add heaps more of them. Unsure of how many exploits are the core's fault.

    Wordpress runs on top of PHP which has it's own security issues and is widely facing the internet ready to be exploited. And you have a database there in the mix too.

    Wordpress has three main areas that need constant attention: Wordpress, PHP and MySQL (typically) and throw in the web server too = 4.

    Folks need all that just to blather and collect occasional comments? That is a huge overhead just for that. Most folks would do better, scale better, etc. with custom rolled straightforward software they understand and is able to be understood.

    I tend to isolate dynamic tools to a production server which pumps out static versions near-time. Pretty simple. Scales like crazy and I can worry about production servers users pound that are Nginx-only.

    If dynamic stuff is needed, there is a server or VPS for that. Like conversations/comments on blog entries. If that gets dragged down, we lose that limited functionality due to attack, hack, etc. All the static, dead printed material still works :)

    Thanked by 1Nexus
  • Do you mean avoid tools like SQL Buddy / phpmyadmin? >

    PHP front ends for MySQL are just keeping you from learning MySQL. When something breaks and the CLI is needed for MySQL you are emergency forced to learn = bad idea. Some of them are nice though :)

    Lots of data we muck with is too big to be dealt with usually with the PHP admin tools. They have their place, but I'd be might careful having them exposed in any way.

    I mean rolling the common stuff, blogs, comments, etc.

    Software for web is rather simple and should be super light weight to no weight. Less baggage ports to new machines well and doesn't require oddball forum support which often can lead to more problems than solutions (especially when in emergency mode).

    Thanked by 1Nexus
  • There are benefits and drawbacks to using either a popular application like Wordpress and using something that you've written yourself.

    With, for example, Wordpress, you get the benefit of many people reviewing the code and finding/fixing exploits. The drawback is that when there is an exploit, it's widely available extremely quickly, and you have a giant target on your back until you patch it. You're more likely to be exploited by some random person scanning using a botnet.

    With a custom application, you don't have the benefit of multiple eyes on your code looking for exploits, but because it's not a popular widely used application, you're relatively safe from random people scanning websites for known exploits. It's security by obscurity, to a degree. However, you're probably more likely to be compromised by someone who has a problem with you and is targeting you specifically - someone you've banned or written a negative review about, or whatever.

    Lead Developer - HostGuard Control Panel

    Thanked by 1Nexus
  • Good summary of the situations @NickM.

    Something like Wordpress has the plugin issue too. So you have exploit potential across many pieces and different authors who aren't going to be so quick to patch and update if at all.

    Thanked by 1Nexus
  • Wordpress plugins are definitely a problem. As far as I know, they receive little if any review from the developers of Wordpress. In any case, standard best practices such as privilege separation, routine backups, and reviewing logs (among other things) can minimize the likelihood and impact of a security breach.

    Lead Developer - HostGuard Control Panel

  • fresher_06fresher_06 Member
    edited October 2012

    Guys .. can we more concentrate on the checklist something like @mount and @mrowen have provided above ..

    Thanked by 1Nexus
  • ReeRee Member

    +1 to ditching mysql_real_escape_string in favour of prepared statements. The introduction page for the mysql_* functions says it all:

    This extension is not recommended for writing new code. Instead, either the mysqli or PDO_MySQL extension should be used.

  • joepie91joepie91 Member
    edited October 2012

    @gsrdgrdghd said: Just run every POST and GET through the appropriate filters mysql_real_escape_string, htmlspecialchars, etc.

    No. Don't. You'll fuck up some bit of data at some point. Overzealous 'sanitation' is just as bad as no sanitation at all.

    The question isn't just how to secure things, the question is how to secure things without negatively affecting other things, such as data integrity.

    • Use parameterized queries for all database queries, no matter what it is. Don't use mysql_*.
    • Use htmlspecialchars() when outputting anything that is not supposed to be HTML. Do not use htmlspecialchars before inserting things into your database! The data in your database should always be the original untouched data. You really do not want to have to fix inconsistent data later because you made a mistake somewhere (if fixing the data is possible in the first place). Also don't use htmlentities(), it doesn't play nice with Unicode data.
    • Properly hash passwords using something like a few thousand rounds of SHA256/SHA512 (using the crypt() function). Do not use md5. Do not use SHA1. Do not use bcrypt (Blowfish), it has a character limit and can actually cause dangerous situations. Absolutely never ever ever ever EVER store any kind of password in plaintext.
    • Make wrong code look wrong. Name your variables along the lines of $uUsername and $sUsername to indicate whether a variable holds safe or unsafe data.
    • Back up your data with a script. Use something that can only push files and not pull or delete them, such as a push over HTTP or a write-only FTP account.
    • Use keypair authentication over SSH and disable password authentication entirely.
    • Never reuse passwords, anywhere. Use something like KeePass (or KeePassX) to store unique passwords for everything.
    • Probably the most important one of all: don't ignore advice of others just because you're used to doing it differently. Take their advice seriously and if there's a point to it, adapt. Pretty much every large fuck-up in web security I've seen so far has been because of someone not following the advice of someone else - usually they would either claim that "it's not that bad to do it like I do" or "there's no need for that".

    Appreciate my posts/software/guides? Donate (PayPal/Flattr/Bitcoin): http://cryto.net/~joepie91/donate.html | irc.freenode.net #lowendbox

  • gsrdgrdghdgsrdgrdghd Member
    edited October 2012

    I was under the impression that @fresher_06 was working with an existing (non-PDO) project since he mentioned mysql_real_escape_string. I agree that for new projects only PDO should be used.

    @joepie91 said: Use htmlspecialchars() when outputting anything that is not supposed to be HTML. Do not use htmlspecialchars before inserting things into your database!

    That can lead to very nasty things one wouldn't think of at first, e.g. people putting HTML code in their browser agent, thus triggering XSS bugs in statistics scripts or PMA.

    President Of Operations/CEO/CFO/CTO/COO of my account
    image

    Thanked by 1Nexus
  • @gsrdgrdghd said: That can lead to very nasty things one wouldn't think of at first, e.g. people putting HTML code in their browser agent, thus triggering XSS bugs in statistics scripts or PMA.

    That's a problem with your stats script / PMA then.

    Lead Developer - HostGuard Control Panel

    Thanked by 1Nexus
  • jcalebjcaleb Moderator

    Host your website at hostbluff. So much secure with their guaranteed downtime =)

    Thanked by 2Nexus klikli
  • fresher_06fresher_06 Member
    edited October 2012

    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

    Thanked by 1Nexus
  • NexusNexus Member
    edited October 2012

    MySQL Vulnerability if entering a negative number. Check for < 1 and error/exit out. If you want more detailed answers / help you can try posting your script here.

    Also use this for correct email formatting server side.

    Also this will help a ton.

    D4jsp - Where virgins roam free
  • As a Wordpress user for over 4 years, I recall little if not less than one or two issues affecting WP core. It's all been third party, contributed plugins or themes by questionable programmers.

    A popular example of a vulnerable theme is the TimThumb.php vulnerability that was fixed by plugin developers but still lived for months in themes that had TimThumb.php hard coded in

    PrismaVPS - Kansas City and Romania OpenVZ VPS Hosting. Plans start at $4/mo
    Thanked by 1Nexus
  • @gsrdgrdghd said: That can lead to very nasty things one wouldn't think of at first, e.g. people putting HTML code in their browser agent, thus triggering XSS bugs in statistics scripts or PMA.

    And that is why you use htmlspecialchars when outputting. If some piece of third-party software fucks up, then get better third-party software.

    Appreciate my posts/software/guides? Donate (PayPal/Flattr/Bitcoin): http://cryto.net/~joepie91/donate.html | irc.freenode.net #lowendbox

    Thanked by 1Nexus
  • joepie91joepie91 Member
    edited October 2012

    @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

    A few issues I can see: * You should be using PDO, not mysql_* * You're doing mysql_real_escape_string before hashing a password. You should be hashing the password that the user gave you, not an escaped version of it. * You should be using the crypt() function with a few thousand rounds of SHA256, not the hash() function.

    Positive point: you are correctly putting the MySQL field names in backticks - very few people do this :)

    Appreciate my posts/software/guides? Donate (PayPal/Flattr/Bitcoin): http://cryto.net/~joepie91/donate.html | irc.freenode.net #lowendbox

    Thanked by 1Nexus
  • Got the below useful Tutorial -- seems interesting

    http://www.openwall.com/articles/PHP-Users-Passwords

    Thanked by 1Nexus
  • joepie91joepie91 Member
    edited October 2012

    @fresher_06 said: Got the below useful Tutorial -- seems interesting

    http://www.openwall.com/articles/PHP-Users-Passwords

    From what I was able to find, PHPass will attempt to use Bcrypt - which is an insecure algorithm in the sense that it will silently cut off passwords longer than 50 characters or so. It's better to use crypt() with a different algorithm such as SHA256/SHA512.

    EDIT: With a few thousand rounds, of course.

    Appreciate my posts/software/guides? Donate (PayPal/Flattr/Bitcoin): http://cryto.net/~joepie91/donate.html | irc.freenode.net #lowendbox

    Thanked by 1Nexus
  • @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.

    President Of Operations/CEO/CFO/CTO/COO of my account
    image

    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.

    Lead Developer - HostGuard Control Panel

    Thanked by 1Nexus
  • joepie91joepie91 Member
    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?

    Appreciate my posts/software/guides? Donate (PayPal/Flattr/Bitcoin): http://cryto.net/~joepie91/donate.html | irc.freenode.net #lowendbox

    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?

    "Go cheap on rarely used things"

    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.

    President Of Operations/CEO/CFO/CTO/COO of my account
    image

    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.

    Quis custodiet ipsos custodes?
    http://raymii.org - http://sparklingnetwork.nl - Need a VPS Control Panel? http://z1s.org/ - Need a VPS that doesn't suck? https://www.digitalocean.com/?refcode=7435ae6b8212
  • @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.

    Quis custodiet ipsos custodes?
    http://raymii.org - http://sparklingnetwork.nl - Need a VPS Control Panel? http://z1s.org/ - Need a VPS that doesn't suck? https://www.digitalocean.com/?refcode=7435ae6b8212
  • 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 :-).

  • @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."

    Appreciate my posts/software/guides? Donate (PayPal/Flattr/Bitcoin): http://cryto.net/~joepie91/donate.html | irc.freenode.net #lowendbox

  • @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
    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).

    Appreciate my posts/software/guides? Donate (PayPal/Flattr/Bitcoin): http://cryto.net/~joepie91/donate.html | irc.freenode.net #lowendbox

  • @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.

    President Of Operations/CEO/CFO/CTO/COO of my account
    image

  • @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.

    Quis custodiet ipsos custodes?
    http://raymii.org - http://sparklingnetwork.nl - Need a VPS Control Panel? http://z1s.org/ - Need a VPS that doesn't suck? https://www.digitalocean.com/?refcode=7435ae6b8212
  • 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
    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.

    Appreciate my posts/software/guides? Donate (PayPal/Flattr/Bitcoin): http://cryto.net/~joepie91/donate.html | irc.freenode.net #lowendbox

    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.

  • @kamalnasser said: I suggest you read this: http://phpacademy.org/forum/viewtopic.php?f=28&t=15356

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

    Quis custodiet ipsos custodes?
    http://raymii.org - http://sparklingnetwork.nl - Need a VPS Control Panel? http://z1s.org/ - Need a VPS that doesn't suck? https://www.digitalocean.com/?refcode=7435ae6b8212
  • @kamalnasser said: I suggest you read this: http://phpacademy.org/forum/viewtopic.php?f=28&t=15356 "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.

    Appreciate my posts/software/guides? Donate (PayPal/Flattr/Bitcoin): http://cryto.net/~joepie91/donate.html | irc.freenode.net #lowendbox

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

Sign In or Register to comment.