Page 2 of 2

Posted: Mon May 01, 2006 7:13 am
by timvw
All depends on the defintions of 'random' and 'password'.. I usually take a substring of md5(time())

Posted: Mon May 01, 2006 7:17 am
by hawleyjr
timvw wrote:All depends on the defintions of 'random' and 'password'.. I usually take a substring of md5(time())
Which is pretty much what I'm doing with my function.

Posted: Mon May 01, 2006 8:40 am
by Ollie Saunders
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

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;
}
It 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

esimocic!51
iracokof@13
erohared*41
ecafenat$14
erokoteg!54
eporibas&36
apetelir!24
If you want to use the javascript you'll need to call it like this:

Code: Select all

passGen(document.getElementById('sometextfield'));

Posted: Mon May 01, 2006 11:15 am
by someberry
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.

Posted: Mon May 01, 2006 1:10 pm
by Roja
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.
That depends on a few things.

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.

Posted: Mon May 01, 2006 1:30 pm
by Benjamin
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. Most passwords are single words located in a dictionary which would be much easier to crack than something like Jejgi$39<.

Posted: Mon May 01, 2006 5:33 pm
by someberry
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.

Posted: Mon May 01, 2006 6:30 pm
by Roja
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.
On that much we totally agree. I was offering alternatives for strong passwords that are more memorable. :)
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.
My point remains that fixed patterns by themselves do not make for an insecure choice.

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.

Posted: Mon May 01, 2006 7:56 pm
by alex.barylski
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 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;
}
It 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

esimocic!51
iracokof@13
erohared*41
ecafenat$14
erokoteg!54
eporibas&36
apetelir!24
If you want to use the javascript you'll need to call it like this:

Code: Select all

passGen(document.getElementById('sometextfield'));
Thats pretty clever... 8)

Posted: Tue May 02, 2006 1:52 am
by Ollie Saunders
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.
Yep :) although I don't use every vowel and consonant because otherwise you get lots of words with xywv which are hard to read
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.
Thats pretty clever... 8)
Thanks. There are probably superior methods out there but that is a simple concept that anyone can write.

Posted: Tue May 02, 2006 3:15 am
by someberry
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.
Actually if you look as his code, his patter combinations are:

Code: Select all

4 * 14 * 4 * 14 * 4 * 14 * 4 * 14 * 8 * 10 * 10 = 7,867,596,800
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.

Lets 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,000
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.

Code: 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>');
?>
Which outputs:

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).

Posted: Tue May 02, 2006 7:54 am
by Roja
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.
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.

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.

Posted: Tue May 02, 2006 9:43 am
by someberry
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.
And if one has Javascript disabled?
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.
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.

One still can still create memorable passwords with greater security, just it's a little bit less likely.
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.
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.

Posted: Tue May 02, 2006 11:13 am
by Ollie Saunders
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.
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.
The passwords generated by that script are A LOT more secure that the average memorable password a user provides.
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.
Let me put this into context for you.

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.