Strong password generation...
OK i need to generate some random strong passwords.
I will be using keys a-z A-Z 0-1 and the special keys on the "numeric row" of the keyboard.
is something like:
publicstaticchar[] generateStrongPassword(int length){
char[] pwd =newchar[length];
java.util.Random rGen =new java.util.Random();
for (int i = 0; i < length; i++)
pwd[i] = pwdChars[Math.abs(rGen.nextInt() % pwdChars.length)];
return pwd;
}
privatestaticchar[] pwdChars ="abcdefghijklmnopqrstuvqxyzABCDEFGHIJKLMNOPQRSTUVWXYZ`1234567890~!@#$%^&*()".toCharArray();
the way to go? or should i find a better random # generator? or even "randomize" the character array for pwdChars?
The only problem with this is that if someone knows the algorithm and the approximate time of generation and the length of the password, that person can generate a list of passwords that will contain the one generated.
On way you can remove that is to have a human operator enter a string that you can use in combination with the current time to seed the Random. There's probably other, better methods out there.
probably add some kind of "salt" to the seed to modify it in some way? perhaps the amount of free memory in the system at the time of code execution? i would guess that would be hard to "figure out"
> should i find a better random # generator?I'd use a SecureRandom to generate passwords.
Perhaps. I'm no security expert, though. I was also thinking that if you generate two Randoms with buch of yields and sleeps in between that you would probably get spans between current times on each run. Another thing you could do is store a the seed on disk and load it everytime the app runs. This presents it's own problem, though.
> > should i find a better random # generator?> > I'd use a SecureRandom to generate passwords.awesome i will take a look at that, thanks
> Perhaps. I'm no security expert, though. I was also
> thinking that if you generate two Randoms with buch of
> yields and sleeps in between that you would probably
> get spans between current times on each run. Another
> thing you could do is store a the seed on disk and
> load it everytime the app runs. This presents it's
> own problem, though.
i found this for somewhat of a way to go for secure #'s, but i think i will go w/ java's secure number generator
From - Sat Mar 9 16:19:41 1996
Path: news.isaac.cs.berkeley.edu!not-for-mail
From: strick -- henry strickland <strix@versant.com>
Newsgroups: isaac.lists.coderpunks
Subject: java spinner
Date: 6 Mar 1996 13:53:31 -0800
Organization: ISAAC Group, UC Berkeley
Lines: 66
Sender: bin@abraham.cs.berkeley.edu
Approved: mail2news@news.isaac.cs.berkeley.edu
Distribution: isaac
Message-ID: <9603062024.AA25642@vp.versant.com>
NNTP-Posting-Host: abraham.cs.berkeley.edu
Precedence: bulk
// Thought i should share this. can you simplify? --strick
//
// (A) 1996, Henry Strickland, no rites rzrvd.
class SpinStop extends Throwable {
SpinStop() {}
}
class SpinSlave extends Thread {
long millis;
Thread parent;
SpinSlave(long millis, Thread parent) {
this.millis= millis;
this.parent= parent;
}
public void run() {
try {
Thread.sleep(millis);
parent.stop(new SpinStop());
stop();
} catch (InterruptedException ex) {
parent.stop(ex);
}
}
}
class SpinMaster extends Thread {
long millis;
long counter;
SpinMaster(long millis) {
this.millis= millis;
this.counter= 0;
}
public void run() {
try {
Thread t= new SpinSlave(millis, this);
t.start();
while (true) {
counter ++;
Thread.yield();
}
} catch (SpinStop s) {
}
}
}
public class Spinner {
public static long spin(long millis) throws InterruptedException {
SpinMaster t= new SpinMaster(millis);
t.start();
t.join();
return t.counter;
}
}
// end.
and if anyone wants the code, here is a pretty "secure" way for random numbers, utilizing the java.security.SecureRandom number generator:
and if anyone has any suggestions please let me hear them
public static char[] generateStrongPassword(int length) {
char[] pwd = new char[length];
try {
java.security.SecureRandom random = java.security.SecureRandom.
getInstance("SHA1PRNG");
byte[] intbytes = new byte[4];
for (int i = 0; i < length; i++) {
random.nextBytes(intbytes);
pwd[i] = pwdChars[Math.abs(getIntFromByte(intbytes) % pwdChars.length)];
}
}
catch (Exception ex) {
// Don't really worry, we won't be using this if we can't use securerandom anyway
}
return pwd;
}
private static int getIntFromByte(byte[] bytes) {
int returnNumber = 0;
int pos = 0;
returnNumber += byteToInt(bytes[pos++]) << 24;
returnNumber += byteToInt(bytes[pos++]) << 16;
returnNumber += byteToInt(bytes[pos++]) << 8;
returnNumber += byteToInt(bytes[pos++]) << 0;
return returnNumber;
}
private static int byteToInt(byte b) {
return (int) b & 0xFF;
}
private static char[] pwdChars = "abcdefghijklmnopqrstuvqxyzABCDEFGHIJKLMNOPQRSTUVWXYZ`1234567890~!@#$%^&*()".toCharArray();
A big problem with these pseudo-random passwords, is they are so garbled, they look strong but are weak in two ways, 1) A quick decompile of the source could reveal the algorithm. 2) they need to be written down by the user. These both present massive weakness.
I've always though that joining 2 random works from a dictionary is a good idea. You can download free dictionaries from with web with 60,000 words in them. By choosing two words you have 3.6 Billion combinations, and 3 words is 2.16E14.
If those words are choosen with an external quasi-random function, such as the lsb from the time-gap between a user hitting 16 keys, you have a pretty good randomising function.
> 1) A quick decompile of the source could
> reveal the algorithm.
I agree with having to write down the password as being a vulnerability but the API for SecureRandom suggests to that even if you have the algorithm, you can't guess the password even if you know exactly when it was generated.
> A big problem with these pseudo-random passwords, is
> they are so garbled, they look strong but are weak in
> two ways, 1) A quick decompile of the source could
> reveal the algorithm. 2) they need to be written down
> by the user. These both present massive weakness.
>
> I've always though that joining 2 random works from a
> dictionary is a good idea. You can download free
> dictionaries from with web with 60,000 words in them.
> By choosing two words you have 3.6 Billion
> combinations, and 3 words is 2.16E14.
>
> If those words are choosen with an external
> quasi-random function, such as the lsb from the
> time-gap between a user hitting 16 keys, you have a
> pretty good randomising function.
I believe passwords that include a-z A-Z numbers and punc that have ~9 chars are 56-bit and ~20 chars are 128-bit so the time and logic to figure them out would be quite extensive.
that function assuming 20 characters is 20^74 is 1.88e96, so i assume that is a bit more random than dictionary words...
again the problem of having them written down comes into play, but i am taking that into account as an acceptable issue to ignore (for the time being).
and to note, having the source is a non-issue, you should assume someone can always get the source of your algorithm, and build around that. assuming otherwise is asking for trouble
I remember reading somewhere (maybe in the docs for SecureRandom) that using thread scheduling as presented above is not particularly secure, though I don't think it said why.
jverd at 2007-7-7 1:31:42 >
My security advice is to ignore all advice on security matters that comes from a public forum such as this one given by folks with no known credentials in security and no known party affiliations. For all you know us terriorists that routinely monitor these froums looking for opportunities to inflict,TERROR, have just encouraged you to use a technique that we KNOW that we can easily crack and next thing ya know we will be reading your secrets, and charging for our WMDs on your credit cards.
NYA HA HA!!!!
IMHO the flaws that folks have pointed out in the algorithm that you first suggested are inconsequential for any purposes outside of the NSA and the improvements suggested by my fellow poster here are at best weak for any genuine "strong security" need. There is security and there is bullshit. and passwords I am sorry to say are bullshit.
That is just my opinion. My first chunk of advice holds, namely be very suspicious of advice on security from folks, such as myself, that pretend to be experts. If you don't know what your'e doing, don't do it, and if you do know, than don't tells us about it. Don't Ask, Don't Tell.
Be paranoid
and have a nice day!
> There is security and there is bullshit. and passwords> I am sorry to say are bullshit.So why bother setting the password on your database at all? Just make it admin:admin. It's just BS anyway.
"Spaceballs" What is the password?12345What kind of IDIOT would make 12345 a password?
> What kind of IDIOT would make 12345 a password?It's ingenious. No one would expect the password to be '12345'.
> "Spaceballs"> > What is the password?> 1> 2> 3> 4> 5> > > What kind of IDIOT would make 12345 a password?That's amazing. I have the same combination on my luggage.
>> "Spaceballs"
>>
>> What is the password?
>> 1
>> 2
>> 3
>> 4
>> 5
>>
>>
>> What kind of IDIOT would make 12345 a password?
>That's amazing. I have the same combination on my luggage.
Hey now..how did you know my Java.sun.com password?
1) Find some entropy.2) Hash it.4) Make it human-readable.3) Eat lunch0) Sleep5) Use it for your password.
> or should i find a better random #> generator? If you need your numbers to be truly random you could consider looking at: http://superhappycool.blogspot.com/2004/10/article-really-random-numbers.html
