Mcrypt

PHP
21

I understood you were nit saying I am monkey! :slight_smile: Actually I meant I don’t consider you as my code monkey! :slight_smile:

22

I would personally avoid placing the password hash in a cookie at all. If someone has selected “remember me” are you then setting the expiry date and time of their session to a very long time in the future?

For checking to see if the user’s submitted password matches that stored in the database (which should always be in a hashed form!):

Your best bet is to use the password hashing functions (new to PHP 5.5). This way, you won’t have to specify an algorithm, a cost, or even a salt. It does it all for you, and it does it right. If you need to support versions of PHP earlier tha 5.5, then you can use this [URL=“https://github.com/ircmaxell/password_compat”]forward compatibility library.

23

In my old product i was using md5 password and am moving to password_hash. How to migrate users profile data with new password? I was thinking: first tries to validate with pass_hash if not validate then check password format with regexp, if not password_hash, assuming it is md5, so tries to validate them with md5, if success then update password in db with password_hash. What do you think? Better idea?

24

Here’s how I would approach migrating from MD5.

First, in your database, next to your fields for “hash” and “salt”, make a new field for “algorithm”. For all your current records, “algorithm” can have the value “md5”. This way, you’ll know which algorithm was used to generate which hash, which is better than relying on some trial and error process or regexp matching.

Second, make any new user registrations or password changes save using the password_hash functions. In the database, these new entries can have an “algorithm” value of “password_hash”. This way, your old MD5 hashes and your new password_hash hashes are easily identifiable and can coexist without any conflicts.

Third, with your new records taken care of, now it’s time to strengthen all the old MD5 hashes. We’re going to use a new “algorithm” value that I’ll call “md5+password_hash”. We can’t retrieve the original password to make a clean password_hash, so instead we’re going to make a password_hash of the MD5 hash. This way you still get all the benefits of the new algorithm: stronger security, automatic salting, and computationally intensive. The only catch is that you’ll have to take care when verifying a user’s password. You’ll need to check the algorithm field to decide which is the right way to verify this particular hash.

25

I need to check if a string is a 32-byte string containing only 0-9 and small a-f. Is it a correct regexp?
‘~[1]{32}~’

  1. a-f0-9 ↩︎

26

No answer yet for regexp above?

27

Why do you even need the regex? If your checking to see if it is the new hash syntax or the old MD5 just do:

if ($password[0] != '$') { //Old MD5 hash

  1. a-f0-9 ↩︎

28

No. I need it for something else. Plz say if that regexp is right or no?

29

No it is not correct.

You just check the first part of the string, which means it can be longer and still validate.

I would recommend you to take a look on this software: http://www.regexbuddy.com/

It is by far the best one I have found for writing and testing regexes, and we have been using it for years as it greatly increase our speed when writing and testing complicated regexes.

30

Better to do like that: ‘~[2]{32}$~’, because your patter would match ‘e10adc3949ba59abbe56e057f20f883e’, but also it would match ‘e10adc3949ba59abbe56e057f20f883e hello, it’s sql robbery >: D’.

So you need to add $ in the end of your RegEx to make a rule that it’s from beginning (^) till the end ($).

  1. a-f0-9 ↩︎

  2. a-f0-9 ↩︎