3

How can I sanitize a string that receives a hash+random salt?

I can remove the white spaces, check the length and use mysqli_real_escape_string, but is it sufficient? The filter_var is really useful but it can't help in this case, right?

Tksrm
  • 13
  • 4
daniel__
  • 11,633
  • 15
  • 64
  • 91

3 Answers3

2

If you are going to put the variable in an SQL query, then you either need to call mysqli_read_escape_string or (even better!) use prepared statements.

There's no other sanitization you need to do. However, if the value will be coming from freeform user input (e.g. a text box instead of a drop down menu) then you may also want to trim whitespace and lowercase it as a courtesy to the user (to correct accidental mistakes they might make). It really depends on the application.

Jon
  • 428,835
  • 81
  • 738
  • 806
  • 10
    You should not modify passwords in any way by trimming or lowercasing them. This only aids potential attackers. – deceze Mar 22 '11 at 03:05
  • 1
    @deceze: The title may say password, but the question says hash+salt. Granted, lowercasing the salt will break it, but I think you will agree that in general the idea is ok. And I did say "depending on the application", i.e. don't do it to people's names, but do it to credit card numbers. – Jon Mar 22 '11 at 03:07
  • can you not use a regular expression to also inforce odd characters? – G Gr Mar 22 '11 at 03:12
  • 3
    Lowercasing or uppercasing the password is a very bad idea. Trimming it is good, as it will only kill spaces/new lines/etc. at the beginning and end of the password. There's a reason that a good password has upper and lowercase letters, it doubles number of potential character combinations needed to replicate the password. – Phoenix Mar 22 '11 at 04:35
  • @phoenx - Way more than doubles the possible combinations by the way, extra possible characters increase the combinations possible along an exponential scale. – Jimbo Jonny Aug 07 '12 at 17:16
2

Just to be clear, you're receiving from an un-trusted source a hash (effectively random data) + salt (actually random data), and you want to 'sanitize' it? There is probably a definition of sanity that applies (a data format like base64 encoding, a maximum / expected length), but I strongly suspect there is a functional security mistake in there somewhere.

Most notably, why are you accepting a hash+salt from an un-trusted source, rather than accepting a password and doing the transformation within your trusted environment? Accepting a hash+salt from an un-trusted source probably turns them into plain-text equivalents (you lose the benefit you got from hashing and salting the original password).

Slartibartfast
  • 1,694
  • 9
  • 8
-1

First validate that the password matches your given validation rules. You can use a regular expression for this. Often passwords may consistent of a-z, 0-9, perhaps some punctuation and must be within a certain length - say 6-12 characters. Use preg_match() to validate the string for its contents and length. Something like preg_match('/^[a-z0-9]{6,12}$/i',$pass) might be a start.

Next you can hash the password. You may use the function crypt() to do so. This will create a one-way encrypted string that you can use to compare against later when the user attemps to authenticate.

Finally, to store the password, yes using mysqli_real_escape_string() will do the trick to prepare it for use in your SQL insert or update statement.

Andrew Yochum
  • 1,056
  • 8
  • 13
  • 2
    It should be noted that a strong password would include both lowercase and uppercase letters, as well as digits and a healthy selection of special characters like !@#$%^&*();:<>,.? to choose from. Also my impression is that it's best to make them at least 8 characters long at a minimum. – Syntax Error Mar 22 '11 at 03:12
  • You should store the hash, not the password. -1 until you clarify that aspect. – Alexandru Guzinschi Sep 27 '15 at 09:48
  • @SyntaxError A strong password is not a password, it is a [passphrase](https://en.wikipedia.org/wiki/Passphrase). – Alexandru Guzinschi Sep 27 '15 at 09:50
  • Technically a passphrase can still be weak and a password can be strong but I agree in spirit as far as best practices go. My previous comment was from 5 years ago when the special characters method was more accepted but I recommend the correcthorsebatterystaple method these days. Also concerning the hash - not sure if you have enough rep to edit answers but that might be better than downvoting if you see instances where very old answers are unclear about dangerous practices. The user you're talking to hasn't been seen in a year for example. – Syntax Error Sep 27 '15 at 14:29
  • @SyntaxError I've seen that is 5 years old, but an update can't hurt and yes, I have enough reputation to edit, but if I edit the post, the poster will learn nothing and could make the same mistake in the future. If he doesn't show up, I will edit it eventually. – Alexandru Guzinschi Sep 27 '15 at 16:02
  • Why allow some characters and not others? that will just annoy your users. – stib Feb 03 '16 at 03:18