PureBasic Forums - English

Is anyone out there using SHA1 encoded user names to prevent the possibility of SQL and other injection infections? It seems to me that this would take care of that, as it is removes the possibility of single quotes, double dashes, and other injection methods from happening.

I use SHA2, plus global salt, plus user specific sale to derive the hash for the password. I believe SHA1 is sufficient for just the user name.

What do you think?

Should work, until you need to display the username.

User name would be stored in the table. Thinking of using the user's birthday as one of the salt.

User name would be stored in the table.

As plain text? Then you are back to the SQL injection problem. Remember that SHA1 is one-way so you're not getting the username back once you did that. How about using (quoted) Base64-encoding? This way you get rid of quotes and stuff while being able to convert it back to text.

Thinking of using the user's birthday as one of the salt.

The salt isn't meant to be secret, only unique. If you use the birthday, it may not be that unique, because most people have birthdays in the same date range. The correct way is to use a random number from PB's CryptRandom(). Alternatively, use RandomSeed(Birthday) then normal Random(MaxInteger). This way the numbers will be more "spread out".

I just use PDO>Prepare.. SHA ciphers waste CPU and RAM cycles and most hosting is metered or has bottlenecks..

Besides most hacker teams aren't even using sql-injection these days. In the rare cases they do it's blind off some back-end CGI script and found with a fuzzer or code auditing. That's not economical unless it's a targeted attack in which case PDO should suffice against any encoding or parsing attacks.

Trond:

1. The plain text would be stored in the table, but would specifically not be a key.
2. So have a random generated number stored as a hidden field in the record? Brilliant! So any password changes would first generate a new random number, then store that in the hidden field, and use it to generate the SHA2 password hash.

Question: should there also be a global salt? One that is used in conjunction with the user specific salt?

tj1010:

1. I will look into PDO>Prepare.
2. A hosted site is not an issue in this case.
3. CGI script also should not be an issue, as I will be writing IIS filters and extensions.

On a side note, it occurred to add a Delay(1000) * numberBadAttempts, which could help discourage any hack attempts? Possibly???

1. Whether the field is a key or not is irrelevant. If you don't escape it your program is vulnerable to an SQL injection. In this case, whenever a user registers.

2. Yes. See here how PHP does it: http://php.net/manual/en/function.password-hash.php

On a side note, it occurred to add a Delay(1000) * numberBadAttempts, which could help discourage any hack attempts? Possibly???

Yes, except it's annoying with such a high delay for normal users. Better use something like 250. But it's actually a lot more complicated, because if you start a new thread for every request the delay doesn't work. If your program is single threaded, you block all other users.

I'll check our PHP's way of doing it. Every field entered via a browser goes through a check parameter process that I wrote.

Very few things I write nowadays are single threaded. 250 might be better, but the way I wrote it, it was per client IP address.

PDO->Prepare handles all escaping and encoding which is why PHP deprecated the old library.

I dont think it's a good protection.
The user name is typicaly not the only thing a user can enter.

https://www.owasp.org/index.php/SQL_Inj ... heat_Sheet

With PB 5.40 you can use bind variables in PB too. This is the preferred and simplest way to prevent any kind of code injection.

freak wrote:With PB 5.40 you can use bind variables in PB too. This is the preferred and simplest way to prevent any kind of code injection.

Outstanding!