[Johnson_boy]

Hey,

I'm interested in the security aspects of programming, and this time my question is about securely storing passwords. While reading about the topic, I've seen a lot of controversial ideas about the best way of doing it. It's clear that the password should be hashed and salted, but how this should be done isn't so straight forward anymore.

Some suggest to hash the password multiple times with different hashes, but this has been proven a bad idea by many sources, so let's just leave it there.

Then there is the concept of hashing the password many times using the same hashing algorithm (introduced here: https://sampforum.blast.hk/showthread.php?tid=417637). Most people seemed to approve this on the SA-MP forums, but further research made me feel less comfortable with this method. The possibility of hash collisions increases, thus making it easier for the hacker to find the original password (source: http://yorickpeterse.com/articles/use-bcrypt-fool/)

Bcrypt seems the best way to go, but it hasn't been ported to SA-MP. In fact, all the hashes available on SA-MP are relatively fast, and thus not very good for storing passwords.

So what are your opinions? What's the best way to do it on a SA-MP server?

[SuperViper]

Use Whirlpool and a salt.

[steki.]

I double-hash with a 16 character salt. w/ md5

[TheChaoz]

Does someone know how to create a CSPRNG salt?

[Johnson_boy]

Quote:

Originally Posted by steki. I double-hash with a 16 character salt. w/ md5

That's a poor choice of hash. MD5 has been proven to have hash collisions, and in addition it's very fast.

This is how long it takes for a powerful gaming rig (dual 7970) to calculate all possible passwords containing uppercase, lowercase, and numbers:

"all 6 character password MD5s 3 seconds
all 7 character password MD5s 4 minutes
all 8 character password MD5s 4 hours
all 9 character password MD5s 10 days
all 10 character password MD5s ~625 days"

Source: http://www.codinghorror.com/blog/201...d-hashing.html

As the salt is usually stored in the same place than the password hash, it doesn't really help against this.

[thefatshizms]

I use Whirlpool with a random generated salt. This bcrypt hash sounds very interesting though.

[Mauzen]

Having a moderate protection for the passwords of your users is important, sure. But is it really THAT important in case of samp, to have the most complex and most secure hashing methods, slowing down the server itself and making it more complicated to use? I claim that any sha or whirlpool will be good enough. It might be breakable with brute force, but seriously, wheres the point in dehashing for weeks or months, just to get the password of some samp server account? Its not about money or private information, the worst thing one could do with that is like banning all users. The hacker kids that would try to "hack" into some admin account will just lose interest after some days, and the serious guys simply arent stupid enough to waste their time with samp account hacking. So just like the fear of deamx, I think that actually noone ever dehashed a password for samp (feel free to prove me the opposite).

Its way more important to keep the database itself safe. Once someone got access to the database, he can do quite all of the same bad stuff, without needing to crack any passwords. If noone can access the passwords, they wouldnt even have to be hashed (except for privacy of course)

[Johnson_boy]

Quote:

Originally Posted by Mauzen Having a moderate protection for the passwords of your users is important, sure. But is it really THAT important in case of samp, to have the most complex and most secure hashing methods, slowing down the server itself and making it more complicated to use? I claim that any sha or whirlpool will be good enough. It might be breakable with brute force, but seriously, wheres the point in dehashing for weeks or months, just to get the password of some samp server account? Its not about money or private information, the worst thing one could do with that is like banning all users. The hacker kids that would try to "hack" into some admin account will just lose interest after some days, and the serious guys simply arent stupid enough to waste their time with samp account hacking. So just like the fear of deamx, I think that actually noone ever dehashed a password for samp (feel free to prove me the opposite). Its way more important to keep the database itself safe. Once someone got access to the database, he can do quite all of the same bad stuff, without needing to crack any passwords. If noone can access the passwords, they wouldnt even have to be hashed (except for privacy of course)

I'm more concerned about the users' privacy than data loss on the SA-MP server. It is a fact that (too) many people use same passwords on many websites and services, including SA-MP. That's why it's vital to keep the passwords safe even though the data on the SA-MP server is not that important.

And of course it is important to keep the database safe, but there is always a chance that an intruder gains access to the data. There's not way to be 100% safe.

[AndreT]

Excellently said.

Furthermore the responsibility in password safety is fully on the server operator and fully on the user. If a server requires an e-mail address to register, I get extra cautious right away. Using the same e-mail address(es) for personal, work-related and miscellaneous Internet-doings is often a bad idea to begin with, so make sure to have plenty. Having an e-mail address which does not hint to your real identity is a good idea. Using different passwords for different identities is a must, though.

For servers that store relatively small amounts of data per player (a.k.a no e-mail address is stored), I think a simple Whirlpool hash will do. Clever salting will give whoever tries to crack the hashes a serious headache, should Whirlpool ever become vulnerable to this (I'm not familiar with its current status). But what's more important is that you should look out for vulnerabilities in your own system including those possibly introduced by the specifics of your storage method (never throw invalidated user AND ADMINS input into a SQL query for example).

And another thing is what people often don't consider is when working with your script debugging enabled or if you have queries printed by default, make sure passwords don't get logged. If you do log raw-text passwords, it'll make the life of your dear hacker a lot more easier.

[playbox12]

Just adding to the bruteforce takes weeks or months. If you have a large hash dump file and some decent rules for your brutefroce attack you can very quickly crack passwords by running it on your GPU. (we are talking billions of passwords per second). Now imagine multiple GPU's or multiple PC's (even clusters of servers, there are websites where you can rent some processing power to crack hashes).

Now we are not even talking about dictionary attacks or Markov, hybrid combinations and so on.

Password security is essential.

http://www.dailymail.co.uk/sciencete...ords-hour.html
http://hackaday.com/2012/12/06/25-gp...our-passwords/

[Y_Less]

Not in this topic, no, but it has been discussed plenty of other times in other topics (including quite recently).

[thefatshizms]

Quote:

Originally Posted by Gamer_Z I read through this topic and it bothers met that NO ONE metioned that each salt HAS TO BE UNIQUE, for each USER, and even if someone changes a password, you need to assign a NEW SALT, that's the whole point of SALTS, making bulk-cracking impractical / almost impossible. If a determined hacker want's only one password salts won't help. AT ALL (well, maybe a little bit..). Actually, I think there would be a lot of potential in a plugin generating Unique salts with each request. How about that? (and don't be shy to use long salts, like 128 chars, it's better than 4 char salts because you can generate unique salts more easily) As for storing password go with what's available at the time - as for now whirlpool. and I think there is a crypto plugin around here which has a few more hash algo's (but it's I think SHA-etc, all these "depreciated" things) [not rly depreciated but you get what I mean]. And as for being a "secure server" - you have to keep in mind the people that actually "forget" to "hide" their identities.

Quote:

Originally Posted by Y_Less Not in this topic, no, but it has been discussed plenty of other times in other topics (including quite recently).

Quote:

Originally Posted by thefatshizms I use Whirlpool with a random generated salt. This bcrypt hash sounds very interesting though.

Not sure if you missed my post or you didn't understand me.. I'm using unique salts

[Johnson_boy]

I was again looking at the various methods used by people to store the password and was not pleased at all. Plain text, MD5 without salts...


So, I decided to try making a way to store the passwords securely:

https://github.com/LassiR/password-samp

The idea is much similar to PHP's password_hash function (new in 5.5). Basically the password is hashed and salted securely, without the programmer having to worry about the security measures.

I'd like you to check it, for possible security flaws, and for feedback overall. If it seems alright, I'm going to release it. I don't want to release a script with bugs, so I'm asking for feedback first.

[Vince]

Some people take this way too far. I'm not saying that security isn't important but there is a limit. 32,000 rounds of hashing is severe overkill. I know for a fact that even large forums use a rather simple hashing algorithm. (FYI: I use a 160 bit salt and 3 rounds of hashing).

[Y_Less]

Quote:

Originally Posted by Vince Some people take this way too far. I'm not saying that security isn't important but there is a limit. 32,000 rounds of hashing is severe overkill. I know for a fact that even large forums use a rather simple hashing algorithm. (FYI: I use a 160 bit salt and 3 rounds of hashing).

"Other people don't care so we shouldn't either" is not a good attitude to take towards security. In this case we have multiple discussions on the issues, people have no excuse not to know.

[Vince]

I'm not even going to argue anymore. Yes I know of the "prepare for what could happen" stuff, but I've yet to see a SA-MP database getting exposed. Mind you that many people also still use udb_hash or the like to "secure" their passwords.

[Johnson_boy]

Quote:

Originally Posted by Gamer_Z I think your idea about "threading" is completely wrong, you can't do threads with pawn itself. That's what plugins are for. also isn't 512 iterations just a bit too overwhelming as a default? (Me for example doesn't care about changing default values of libraries, I *should* trust the librarians)

I know, it has nothing to do with multi-threading, but it's the best name I could come up for it. It's rather distribution of server load, not multi-threading. Basically instead of using 100% of CPU power for a short while, it uses less CPU power during a longer period of time. I have changed the name to load distribution to avoid confusion.

And about having too many iterations, I agree. I have reduced the default cost factor to 13 (8 192 iterations, 130ms) when the load distribution or "threading" is enabled. I will test how long it takes to do this on a less powerful CPU, and might adjust it even lower if necessary. The time it takes to hash the password should be at least 0.2 seconds. (a couple of sources below)

Quote:

Originally Posted by http://blog.ircmaxell.com/2012/12/seven-...crypt.html Ideally, for most usages, each hash should take between 0.25 and 0.5 seconds.

And to support the argument, quoting PHP's documentation:

Quote:

Originally Posted by http://php.net/manual/en/function.password-hash.php Example #4 password_hash() example finding a good cost <?php /** * This code will benchmark your server to determine how high of a cost you can * afford. You want to set the highest cost that you can without slowing down * you server too much. 10 is a good baseline, and more is good if your servers * are fast enough. */ $timeTarget = 0.2; $cost = 9; do { $cost++; $start = microtime(true); password_hash("test", PASSWORD_BCRYPT, ["cost" => $cost]); $end = microtime(true); } while (($end - $start) < $timeTarget); echo "Appropriate Cost Found: " . $cost . "\n"; ?>

And if you consider that being over secure, you may also consider the Moore's law, which implies that the power of computers doubles every year. In addition, the hacker most likely doesn't use a single CPU core to calculate the hashes, but most likely a GPU, which can be a thousand times more powerful (literally).


Edit: I did some benchmarking on my server (cops and robbers) with 110 players online. I hashed a password with cost factor 26, which means 67 108 864 iterations.

Код:

[21:45:49] Hashing completed in 1554950 ms
[21:45:49] Hash: wp$26$o(^1pk(*+(NCbjnLbDk#kmgVNrqMshjC$C5F63D324E4F73C5C4C0CD93318227098506D36BD1729A8CDC14D0A6BE2DBB51B5294CDABA7C08F9B85A8173E59EA8329404B87167AD24E4B47DD02069B0A485

I didn't notice any kind of lag during this, nor did any of the other players. That's why it doesn't really matter whether you iterate it 4 times or 40 000 times. I wouldn't still recommend 70 million times, as it was rather tedious to wait 26 minutes :P So why not to be secure if it doesn't hurt? I can guarantee the user won't bother waiting 0.1s or 0.5s while his/her password is being hashed.

[[HiC]TheKiller]

I know I'm a bit late to this discussion, although I thought I would just chuck my two cents in. I've been around quite a bit of hash cracking in the past year, I've even done a bit of it myself. You would be surprised what is secure and what really isn't. The best advantage you could ever have is being unique. I'm not saying hash a bunch of MD5 hashes of a password and concatenate them, do something really unique. You also want to make it hard for a hash cracker to be able to brute force multiple hashes. This means that you're going to have to give up some of your precious efficiency to keep your users data from being cracked easily by hackers. I'm seeing a lot of "Naaaah, we'll be sweet. Doubt we will get hacked. If we get hacked, shit happens". You can do something to reduce the effect it will have on your users. Saying that others don't do it is not an excuse.

Adding something even as basic as a salt could easily add hours - days to the cracking time of your databases. Take linkedin for example. They were dumb enough to use plain SHA1 hashes, and half of their database got cracked in the first couple of hours after it was leaked. If they just added a salt, the members would have had extra time to simply change their passwords as salts make it so crackers can only individually brute force one hash at once.

This is a big issue but I don't see it being fixed any time in the community soon. I'm no role model, most of my scripts don't have the best password security (although the newer ones which will be released soon do). If you're able to change your password hashing, I highly suggest doing it. More efficiency, or more security? It's up to you.

[[HiC]TheKiller]

Quote:

Originally Posted by Gamer_Z I was actually facing the question right now, on how I would secure the database passwords... and I did go with a simple solution: Just whirlpool, and for a "real unique salt" I couldn't just depend on a random number, so I used the Epoch Time in Miliseconds (highly unlikely two players will register in the same milisecond) and did it like this (pseudocode): Password = Whirlpool_Hash( ToString(RandomNumber(0,0xFFFFFFFFFFFFFFFF)) + InputText + ToString(RegisterDate)); My 2 cents.

I personally wouldn't deem this a very secure hash. If your script is compromised and a hacker discovers the algorithm, you're screwed. I would highly suggest adding a more random salt or at least adding extra rounds to the hash to slow down the hash cracking process.

[Bakr]

I'll go ahead and contribute my two cents regarding the subject. Hopefully it will stir up a little constructive discussion.

I agree that you need to secure your passwords. "Don't be the weakest link in the chain" I believe I read not too long ago regarding this topic. Sure, that is correct, but you act as if SA:MP is the sure-fire way for hackers to expose people's passwords. I am sure if someone had the intelligence to crack an advanced hashing algorithm in the first place they would surely find a more valuable resource. However, let's avoid that point, and say they DO decide to use SA:MP. What next? They unveil the passwords (after having spent several days/weeks/months) and try to use the combinations with known email addresses.

If they are lucky they will be able to access a few accounts. However, how can that be the responsibility of the server owners? One of the most basic lessons taught with using the Internet in any basic computer class is to use separate passwords for each account (and beyond that, common sense). What responsibility is the end-user taking from this? None, because all blame is put onto the server developers.

With that said, should we not care and simply not hash passwords at all? No. Don't be the weakest link in the chain. However, obsessing over something that you ultimately wouldn't be able to control anyway (as pointed out multiple times in this thread, anything can be cracked). Make the effort more difficult, sure, but don't kill yourself over it. There are responsibilities of the server to protect your password to an extent, but you as the user ALSO have a responsibility to protect YOURSELF.

The difference between SA:MP and a huge organizations database is that you don't sign agreements when entering SA:MP servers. You aren't reading and accepting their licenses and policies of how they keep your passwords safe, so you shouldn't expect it either. There is also nothing personally attached to a user who plays on a server. The only thing that could personally damage someone by a SA:MP database leak would be on the ignorance of the user's themselves, not the developers, EVEN IF they store the passwords in plain text (though, that is ignorant in itself).

Basically, I think you need to focus more on the people who idiotically use the same password for a SA:MP server as they do for their credit card account.