generate random password
Moderator: General Moderators
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
when i randomly generate passwords i try to make them as pronounceable as possible because then you can actually remember them but they still aren't real words.
This is javascript but i'm sure you're all smart enough to port it to php
It choose a random consonant then a vowel then a consonent and so on these are the kind of results you can expect:
If you want to use the javascript you'll need to call it like this:
This is javascript but i'm sure you're all smart enough to port it to php
Code: Select all
passGen = function(domTo) {
var sPass = '';
var aChars = [
['a','e','i','o'],
['r','t','p','s','d','f','g','h','k','l','c','b','n','m']
];
var nCharTypes = aChars.length;
var aLengths = [aChars[0].length,aChars[1].length];
var i = 8;
while(i) {
var nMod = i % nCharTypes;
var nRand = Math.floor(Math.random() * aLengths[nMod]);
sPass += aChars[nMod][nRand];
i--;
}
var aSymbol = ['!','$','%','^','&','*','@','#'];
sPass += aSymbol[Math.floor(Math.random() * aSymbol.length)];
sPass += Math.floor(Math.random() * 99);
domTo.value = sPass;
return false;
}Code: Select all
esimocic!51
iracokof@13
erohared*41
ecafenat$14
erokoteg!54
eporibas&36
apetelir!24Code: Select all
passGen(document.getElementById('sometextfield'));That depends on a few things.someberry wrote:Generating passwords with a fixed pattern is plain silly. The point is to make it as random as possible to avoid duplication, guessing and cracking.
The goal of creating "somewhat random" default passwords is to ensure that an attacker will not gain access to it.
Its important to note that there are multiple methods to attack that password: Brute-force, predictive guessing, and also compromise.
We'll assume that compromise isn't an issue. In a nutshell, if the machine on either side is compromised, all the automated security in the world won't help much. Short of a SecureID token, or similar, we can't solve this problem, so we'll focus on the other two.
Brute-force is what most people think of when they try to generate a random password. In that sense, its an easy excercise. You want more characters (longer length), and you want a greater variety of possibilities per character (upper and lowercase, numeric, special characters, etc).
However, keep in mind that a highly random password can be difficult to remember. That leads to considerations like making passcodes instead of passwords. So for example, instead of the five character password ("@a7t%"), which would be incredibly difficult to remember, you could in contrast use the much more memorable password ("Roja_is_a_royal_pain"), and have just as much complexity for a brute force attempt.
You'll notice I've left predictive guessing out. Predictive guessing encompases a number of attacks. From Dictionary attacks, to Rainbow tables, they all boil down to the same concept - it reduces the number of brute-force attacks I have to make, because I know the pattern.
This is why most people believe that a fixed pattern is risky, which isn't the whole story. You can have a fixed pattern, and you can have memorable passwords. The important part is that there is sufficient randomness.
For example: Lets say I wanted to replace that cryptic five-character password with something a user could remember. Five characters, with alphanumeric, and symbols is roughly 94 combinations per character. That to the fifth power is roughly 7 billion combinations. If we have 94 words, and we can put them in any order in five slots to a sentence, guess what? Thats the same amount!
So then instead of @a7t% , we could have "rooster sock fiddle puppet register". Silly, it has a very fixed pattern, but its highly memorable, and nearly impossible to brute force. Better, despite its pattern being predictable, its no less secure.
Passcode generation is about balancing risk with user comfort. Also keep in mind that other controls can help reduce the risk of password compromise even more!
By putting a time delay between bad login attempts on the same IP or same account, you will slow the attacker down. By logging those bad attempts, (and having someone that looks at the failures), you can spot the attack before it succeeds. By locking out accounts after (15?) attempts, you can ensure that you will severely limit the attacker.
By using rigorous controls, even a fixed pattern, memorable, easy to type password can be secure.
Roja, although you are correct in saying some long length passcodes can be just as secure as short passwords, I would choose the short passwords everytime - purely because I have a 13 character passcode for my hotmail account, and I hate having to type it in - I nearly always make a mistake or two every time I login. I also use three eight character passwords which I can remember easily, maybe its just me, but I can roll them off the top of my head no problem - one of them I only ever use about once a month, if that.
But what I was really replying to was the fact that ole made the function using Javascript for everyone and anyone to see, and made it so it had a fixed pattern - consonant, consonant, vowel, etc etc. I find that a little insecure for my liking.
But what I was really replying to was the fact that ole made the function using Javascript for everyone and anyone to see, and made it so it had a fixed pattern - consonant, consonant, vowel, etc etc. I find that a little insecure for my liking.
On that much we totally agree. I was offering alternatives for strong passwords that are more memorable.agtlewis wrote:well forgive me if I am wrong, but I would think that almost any randomly generated password would be more secure than the average passwords created by real people.
My point remains that fixed patterns by themselves do not make for an insecure choice.someberry wrote:But what I was really replying to was the fact that ole made the function using Javascript for everyone and anyone to see, and made it so it had a fixed pattern - consonant, consonant, vowel, etc etc. I find that a little insecure for my liking.
His pattern in possible combinations: 5*21*5*21*5*21*5*21*8*9*9 .
Just because you know the pattern and position of each, doesnt change the fact that you must get all of them correct in a single pass - so the odds do not change. If we were playing a game that told us when we had one position or character right, perhaps. However, in passwords, thats not the case. So, his combinations above = 78,764,805,000. Even at one hundred attempts a second, with no lock out, no delays, it would take 9,116 days.
I think calling that insecure is a little sloppy for my liking.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Thats pretty clever...ole wrote:when i randomly generate passwords i try to make them as pronounceable as possible because then you can actually remember them but they still aren't real words.
This is javascript but i'm sure you're all smart enough to port it to phpIt choose a random consonant then a vowel then a consonent and so on these are the kind of results you can expect:Code: Select all
passGen = function(domTo) { var sPass = ''; var aChars = [ ['a','e','i','o'], ['r','t','p','s','d','f','g','h','k','l','c','b','n','m'] ]; var nCharTypes = aChars.length; var aLengths = [aChars[0].length,aChars[1].length]; var i = 8; while(i) { var nMod = i % nCharTypes; var nRand = Math.floor(Math.random() * aLengths[nMod]); sPass += aChars[nMod][nRand]; i--; } var aSymbol = ['!','$','%','^','&','*','@','#']; sPass += aSymbol[Math.floor(Math.random() * aSymbol.length)]; sPass += Math.floor(Math.random() * 99); domTo.value = sPass; return false; }If you want to use the javascript you'll need to call it like this:Code: Select all
esimocic!51 iracokof@13 erohared*41 ecafenat$14 erokoteg!54 eporibas&36 apetelir!24Code: Select all
passGen(document.getElementById('sometextfield'));
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
YepHis pattern in possible combinations: 5*21*5*21*5*21*5*21*8*9*9 .
Just because you know the pattern and position of each, doesnt change the fact that you must get all of them correct in a single pass - so the odds do not change. If we were playing a game that told us when we had one position or character right, perhaps. However, in passwords, thats not the case. So, his combinations above = 78,764,805,000. Even at one hundred attempts a second, with no lock out, no delays, it would take 9,116 days.
I think calling that insecure is a little sloppy for my liking.
And the system that uses the has an 8 attempts and lock out.
Also external attackers have no way of knowing what the pattern is.
Thanks. There are probably superior methods out there but that is a simple concept that anyone can write.Thats pretty clever...
Actually if you look as his code, his patter combinations are:Roja wrote:His pattern in possible combinations: 5*21*5*21*5*21*5*21*8*9*9 .
Just because you know the pattern and position of each, doesnt change the fact that you must get all of them correct in a single pass - so the odds do not change. If we were playing a game that told us when we had one position or character right, perhaps. However, in passwords, thats not the case. So, his combinations above = 78,764,805,000. Even at one hundred attempts a second, with no lock out, no delays, it would take 9,116 days.
I think calling that insecure is a little sloppy for my liking.
Code: Select all
4 * 14 * 4 * 14 * 4 * 14 * 4 * 14 * 8 * 10 * 10 = 7,867,596,800Lets consider that his 11 character password could be any random string of character (uppercase or lowercase, something ole hasn't done either), numerical, and special characters. I make that 26 (uppercase) + 26 (lowercase) + 10 (numerical) + 10 (special chars, I'm not sure how many there are off the top of my head) = 72 different possibilities per character.
Code: Select all
72 * 72 * 72 * 72 * 72 * 72 * 72 * 72 * 72 * 72 * 72 = 269,561,249,468,963,100,000Code: Select all
<?PHP
$Roja = 5 * 21 * 5 * 21 * 5 * 21 *5 *21 * 8 * 9 * 9;
$ole = 4 * 14 * 4 * 14 * 4 * 14 * 4 * 14 * 8 * 10 * 10;
$prefered = 72 * 72 * 72 * 72 * 72 * 72 * 72 * 72 * 72 * 72 * 72;
echo('<p>Roja\'s total combination: ' . number_format($Roja) . '<br />');
echo('ole\'s real total combination: ' .number_format($ole) . ' (' . number_format(($ole/$Roja)*100) . '% of real combinations).</p>');
echo('<p>More secure combinations: ' . number_format($prefered) . ' (' . number_format(($ole/$prefered)*100) . '% of secure combinations).</p>');
?>Code: Select all
Roja's total combination: 78,764,805,000
ole's real total combination: 7,867,596,800 (10% of secure combinations).
More secure combinations: 269,561,249,468,963,100,000 (0% of real combinations).Security is not an absolute value. His code is not insecure. It is highly secure for the average site, for the average user, for a default password. Further, his other controls (8 attempts lockout) make anything over a few characters highly secure.someberry wrote: Now, I made this little script to test the total combinations, providing there aren't any errors in the code, it shows how insecure ole's code is.
You are trying to nitpick, and complain about his solution, when the reality is that his solution is more than reasonably secure. Better, its reasonably secure AND it gives users a more memorable password.
Ole's code is not insecure. Can it be more secure? Sure. But it would be overkill in the extreme. I'd even argue that it already is.
And if one has Javascript disabled?Roja wrote:Security is not an absolute value. His code is not insecure. It is highly secure for the average site, for the average user, for a default password. Further, his other controls (8 attempts lockout) make anything over a few characters highly secure.
Considering the vast majority of users will change that password as soon as they login, I don't really see the need to create a 'memorable' password for users on the fly, which chances are, is not going to be that memorable.Roja wrote:You are trying to nitpick, and complain about his solution, when the reality is that his solution is more than reasonably secure. Better, its reasonably secure AND it gives users a more memorable password.
One still can still create memorable passwords with greater security, just it's a little bit less likely.
Depends for the site is was designed for to be absolutely honest. A bank wouldn't touch it with a 10ft barge poll, but would be acceptable for a very small website. If it is a very small website though, then the server isn't going to be loaded down, so I don't see it as a problem to add another layer of security.Roja wrote:Ole's code is not insecure. Can it be more secure? Sure. But it would be overkill in the extreme. I'd even argue that it already is.
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
how secure is a password that is difficult to remember?
it'll end up being written down or stored in a file on a user's hard drive.
This script is used on an administration extranet for which there is already a password to get access to. Only someone who has access to the extranet through legitimate or ilegitimate means will be able to see that javascript. The only other way to view that javascript is to have the ftp password to my server which is a very secure password. ilegitimate means are pretty much ruled out because all of the code i've written is secure and throroughly tested to proove so.
In the extranet there is a password field that is used to supply passwords to reports. If no password is specified public access to the report is impossible. User specified passwords must be at least 8 characters. The user has the option to click the a generate password button which runs the passGen() javascript and places the generated password into the field. The user is free to modify the field at any time.
Once the report is created members of the public can get access to it only via the correct URL at which point they are prompted for an HTTP authentication and have to use the correct password. The data contained within the report is not particularly sensitive and the passwording is simply designed to prevent the general public getting access to it.
it'll end up being written down or stored in a file on a user's hard drive.
The passwords generated by that script are A LOT more secure that the average memorable password a user provides.I don't really see the need to create a 'memorable' password for users on the fly, which chances are, is not going to be that memorable.
Let me put this into context for you.I have no problem with the fact that his passwords are very difficult to crack, but that he has used Javascript to implement it with a fixed pattern. What would happen if I turned Javascript off - would I have no password at all?! If it was implemented using some server side language then I don't see it being too much of a problem.
This script is used on an administration extranet for which there is already a password to get access to. Only someone who has access to the extranet through legitimate or ilegitimate means will be able to see that javascript. The only other way to view that javascript is to have the ftp password to my server which is a very secure password. ilegitimate means are pretty much ruled out because all of the code i've written is secure and throroughly tested to proove so.
In the extranet there is a password field that is used to supply passwords to reports. If no password is specified public access to the report is impossible. User specified passwords must be at least 8 characters. The user has the option to click the a generate password button which runs the passGen() javascript and places the generated password into the field. The user is free to modify the field at any time.
Once the report is created members of the public can get access to it only via the correct URL at which point they are prompted for an HTTP authentication and have to use the correct password. The data contained within the report is not particularly sensitive and the passwording is simply designed to prevent the general public getting access to it.