Dessert #3 - Generate a random password
Posted on 15/9/06 by Felix Geisendörfer
Deprecated post
The authors of this post have marked it as deprecated. This means the information displayed is most likely outdated, inaccurate, boring or a combination of all three.
Policy: We never delete deprecated posts, but they are not listed in our categories or show up in the search anymore.
Comments: You can continue to leave comments on this post, but please consult Google or our search first if you want to get an answer ; ).
A neat function I just discovered while looking for a useful CakePHP tip to save me from putting my head into a cake is contained in the NeatString class which rests in /cake/libs/neat_string.php
The function of interest is NeatString::randomPassword($length, $available_chars) which can be used to create a random password with a given $length which is made out of the $available_chars. By default $available_chars contains [A-Z0-9] (All upper case letters + numbers), but you can extend it to use any characters you consider valid for a password (like underscores, dot's, etc.).
The usage of the function is rather simple, but let's take a look at a little example anyway:
Imagine you want to generate a simple password made up of 8 letters in your controller and display it to the user:
$this->set('password', NeatString::randomPassword(8));
Or be a little bit more fancy and allow a whole bunch of other characters:
That's it. Usally you would use this to generate a new password for users that forgot their old one and mail it to them. Or in case you still store passwords in plain text here is another tip: Don't ever do that. Instead store the md5 hash (or some alternative) in the database and then compare the stored hash with the one of the password the user enters when logging in to check for authentication. That way even if you're app has a horrible security hole and somebody get's a hold of your users table, the passwords won't be visible to him. And in case you want to be even fancier, look for a hash algorithm that's available in javascript as well and perform the hashing of the password on the client side so that even a man in the middle attack wouldn't reveal the real password. Combined with a technique like 1-time-challenge you can also take care of replay attacks.
--Felix Geisendörfer aka the_undefined
Did you like this blog post? If so, please consider subscribing to the Blog RSS feed.
You can skip to the end and add a comment.
Unless you are using CRAM, or a similar method, hashing on the client side is a really bad idea. For example: in your Db you store the MD5 of passwords, on the client you generate the MD5 of the password and send it to the server; what you have done now is gone through a lot of work to store the password in plaintext. A Man in the Middle attack will succeed because all they need is the MD5 hash, the original password is unnecessary.
scott: I mentioned the problem of replay attacks with my last sentence. Now I didn't go into detail but what I meant with 1-time-challenge was that for each login form, the server provides an additional challenge key (string). The client now builds the md5 hash from a combination of the challenge key and the password and then send this to the server. Once the challenge has been used once it doesn't work it again. So if somebody tries a replay attack he'll fail because the challenge will not work again.
This post is too old. We do not allow comments here anymore in order to fight spam. If you have real feedback or questions for the post, please contact us.
Great tip. This goes to next version of BakeSale.