Need help with password regenerator
Pages: 12
I believe most of you know what a password generator is.
For those who don't: it's a program that can generate a random-looking password, with the exact length that you want, and using only characters that you permit.
There's a problem with this scheme: you need to save the resulting password.
So I was thinking, what about a password regenerator?
A simple design would be to base it on a hashing algorithm. The user gives the "real" password and the length.
The program would hash the real password, and generate the password.
For example (output made up):
The point is: for the same input combination passregen would regenerate the same password, so the user would never have to save the password.
Even better, this design opens the door for abuse:
I need someone to tell me if they see any flaws in the idea (well except from having to clear the shell history every time).
Then I need help with choosing a suitable hash algorithm.
I'm also thinking of a "binary" mode, whereby passregen outputs non-text keys. This too puts strain on the choice of hash algorithm.
Finally I'd like a guesstimate of effectiveness.
My intuition tells me that cracking the input combination should be quite difficult (especially when piped) but I am ignorant of the math, so I can't be sure.
Thanks for reading.
For those who don't: it's a program that can generate a random-looking password, with the exact length that you want, and using only characters that you permit.
There's a problem with this scheme: you need to save the resulting password.
So I was thinking, what about a password regenerator?
A simple design would be to base it on a hashing algorithm. The user gives the "real" password and the length.
The program would hash the real password, and generate the password.
For example (output made up):
$ echo "MyPassword" | passregen 12 K93hIaVjj0mF |
The point is: for the same input combination passregen would regenerate the same password, so the user would never have to save the password.
Even better, this design opens the door for abuse:
$ echo "MyPassword" | passregen 12 | passregen 100 | passregen 13 kJd09jHHa12q6 |
I need someone to tell me if they see any flaws in the idea (well except from having to clear the shell history every time).
Then I need help with choosing a suitable hash algorithm.
I'm also thinking of a "binary" mode, whereby passregen outputs non-text keys. This too puts strain on the choice of hash algorithm.
Finally I'd like a guesstimate of effectiveness.
My intuition tells me that cracking the input combination should be quite difficult (especially when piped) but I am ignorant of the math, so I can't be sure.
Thanks for reading.
Let me get this straight, you have a program that generates passwords and stores them somewhere (I think), and allows the user to enter a word/phrase that is associated with that password so that they can then get that password back later?
Is the above what you mean, if not please explain again.
Is the above what you mean, if not please explain again.
closed account (Dy7SLyTq)
no hes not actually storing it; hes hashing it so the user will get the same value again and again if they keep inputting the same length and key.
In that case all you are doing is converting a password/phrase given by the user into another form. This could be useful, in that people will not have to remember complex passwords, but rather a phrase and a number. However, it could be used by crackers to crack passwords in a similar way they do now.
closed account (Dy7SLyTq)
see thats what i thought, but they would have to get the initial string, the number of pipes, and the value for each instance of passregen
I guess that in the end, even if done right (i.e. hash algorithm chosen well), this tool would still be more about convenience than security.
If your computer is secure enough to run passregen safely, then it's secure enough to just store the complex passwords in the first place.
Some dirty tricks could be used to increase the "cracking" resistance. For example, using a regular file instead of a phrase. Or having the program generate a random S-Box thing on first use (and if the user loses that file, sad day for him).
In the end, this is all starting to appear clumsy.
If your computer is secure enough to run passregen safely, then it's secure enough to just store the complex passwords in the first place.
Some dirty tricks could be used to increase the "cracking" resistance. For example, using a regular file instead of a phrase. Or having the program generate a random S-Box thing on first use (and if the user loses that file, sad day for him).
In the end, this is all starting to appear clumsy.
There are programs for keeping passwords for you -- you just need to provide one master password and then you can access your other passwords via cut and paste. The nicer programs even hook your system to try to prevent loggers from eyeballing them.
| In the end, this is all starting to appear clumsy. |
Don't give up on it, it sounds pretty good.
So you want the kind of temporary passwords generated when you lose an accounts details?
Try using the rand(), a random number generator. Then just limit it within the ASCII charactersun (the ones that exist on a keyboard and are printable)... If you don't know how to do this it's just using the modulus operator to limit the range, them plus to set the lower bound (upper bound is lower plus range but you don't need it in program)
Try using the rand(), a random number generator. Then just limit it within the ASCII charactersun (the ones that exist on a keyboard and are printable)... If you don't know how to do this it's just using the modulus operator to limit the range, them plus to set the lower bound (upper bound is lower plus range but you don't need it in program)
| Duoas wrote: |
|---|
| There are programs for keeping passwords for you -- you just need to provide one master password and then you can access your other passwords via cut and paste. |
This is exactly what the program is set out against.
The goal is to never store passwords, but to regenerate them.
| giblit wrote: |
|---|
| You could also just RSA encrypt the passwords fairly easy and secure. |
Give more detail please, because I don't know what you have in mind.
RSA is an asymmetric cipher not a hash algorithm. So from the get-go there's an extra piece of information, the public key.
So please explain the thought process, because otherwise this just doesn't look like what I want to achieve.
Unless you also keep track of all the one-way functions used to hash the passwords, and know which one is used for a particular service, there is no way you can regenerate every password you need.
(Besides which, hashes have collisions, so the regenerated password might be different than the original.)
Keeping the hash somewhere safe is about as secure as keeping the plaintext somewhere safe.
(Besides which, hashes have collisions, so the regenerated password might be different than the original.)
Keeping the hash somewhere safe is about as secure as keeping the plaintext somewhere safe.
There seems to be a major misunderstanding, caused in part by my usage of the word "regenerate", so I'll try to clear things up now.
This thread has two purposes:
1) Asking for advice on creating a "hash" algorithm whose output can be used as strong passwords.
2) Asking if this is a good idea.
Basically the passregen utility would function similarly to md5sum, with two differences:
a) The resulting hash code would contain more than just hexadecimal digits.
b) The user could specify the length of the resulting hash code.
So as you can see, this would be quite a goofy atypical "hash algorithm".
So I need advice on how to design and implement it properly.
And I'd also like to know if others see flaws in the main concept.
This thread has two purposes:
1) Asking for advice on creating a "hash" algorithm whose output can be used as strong passwords.
2) Asking if this is a good idea.
Basically the passregen utility would function similarly to md5sum, with two differences:
a) The resulting hash code would contain more than just hexadecimal digits.
b) The user could specify the length of the resulting hash code.
So as you can see, this would be quite a goofy atypical "hash algorithm".
So I need advice on how to design and implement it properly.
And I'd also like to know if others see flaws in the main concept.
Why not double or triple SHA-512 (or whatever other method you find fun) the users phrase.
And then using the binary representation, modulo each 8-bit segment by the number of characters specified (by you or user) and then take the first N (being the number inputted by the user) characters of this.
Example:
Suppose you SHA-256 "cheese" (without the quotes) you get:
873ac9ffea4dd04fa719e8920cd6938f0c23cd678af330939cff53c3d2855f34
Now converting the first 16 bits to binary you get:
10000111 00111010
Now assume that you only have a 52 character table (upper and lower case alphabetical characters) you modulo each 8-bit section by 52 giving you:
00011111 00000110
(i.e. 31 and 6 in decimal)
You now match these on your table (does not have to be in sequence) and you would get a two character password, that will be regenerated whenever you input cheese and the number 2.
Is that kinda what you are looking for?
Bear in mind you could always use multiple hashing algorithms combined or even make your own.
And then using the binary representation, modulo each 8-bit segment by the number of characters specified (by you or user) and then take the first N (being the number inputted by the user) characters of this.
Example:
Suppose you SHA-256 "cheese" (without the quotes) you get:
873ac9ffea4dd04fa719e8920cd6938f0c23cd678af330939cff53c3d2855f34
Now converting the first 16 bits to binary you get:
10000111 00111010
Now assume that you only have a 52 character table (upper and lower case alphabetical characters) you modulo each 8-bit section by 52 giving you:
00011111 00000110
(i.e. 31 and 6 in decimal)
You now match these on your table (does not have to be in sequence) and you would get a two character password, that will be regenerated whenever you input cheese and the number 2.
Is that kinda what you are looking for?
Bear in mind you could always use multiple hashing algorithms combined or even make your own.
That would be cool, to have a normal password, and then enter it into your program, and it would generate a really strong password from yours.
Is that what you mean?
And when you wanted to access that one, just enter the normal password, and it gives the super one every time.
Is that what you mean?
And when you wanted to access that one, just enter the normal password, and it gives the super one every time.
@ Script Coder: I guess that could work for generating "regular" passwords, but I'm also thinking about a binary mode, where the output is non-text.
@ Superdude: yes, that's the idea.
@ Superdude: yes, that's the idea.
| I guess that could work for generating "regular" passwords, but I'm also thinking about a binary mode, where the output is non-text. |
Then all you do is not modulo the output. But AFAIK there are no passwords that you are able to enter in binary format. Also, define "regular" vs "non-regular"?
| Then all you do is not modulo the output. |
Yes but I don't like that you basically use the plain hash code.
Overall that's a good suggestion but my gut feeling tells me I should design my own hash algorithm specifically for this purpose. Still pondering what I should do.
| But AFAIK there are no passwords that you are able to enter in binary format. |
Some applications, such as TrueCrypt, support "keyfiles". Now if we regenerate passwords, we might as well go one step further and regenerate key-files as well.
| Also, define "regular" vs "non-regular"? |
I believe you already figured out that by "regular" I mean text passwords. The "non-regular" would be binary passwords (or non-text key-files).
@Superdude
That's how passwords normally work. You put in your password and the software generates a unique (hopefully) hash. All this is doing is hashing (part of) a hash. If someone figures/finds out that the password itself is a hash, then they've still only got to crack one hash (which, incidentally, Catfish666, is why you shouldn't design your own hashing algorithm [unless you're sure you can design one at least as secure as whatever scheme is used by the server, so probably SHA2]). It may even be easier since presumably you're not going to use the entire hash, and because the hash you're generating won't be salted like the hash stored on the server probably is.
That's how passwords normally work. You put in your password and the software generates a unique (hopefully) hash. All this is doing is hashing (part of) a hash. If someone figures/finds out that the password itself is a hash, then they've still only got to crack one hash (which, incidentally, Catfish666, is why you shouldn't design your own hashing algorithm [unless you're sure you can design one at least as secure as whatever scheme is used by the server, so probably SHA2]). It may even be easier since presumably you're not going to use the entire hash, and because the hash you're generating won't be salted like the hash stored on the server probably is.
| Catfish666 wrote: |
|---|
| Overall that's a good suggestion but my gut feeling tells me I should design my own hash algorithm specifically for this purpose. Still pondering what I should do. |
Wait so do you want suggestions on a hashing algorithm or how to regenerate passwords? Or did you originally want both and now you want the former of the two?
| chrisname wrote: |
|---|
| It may even be easier since presumably you're not going to use the entire hash, and because the hash you're generating won't be salted like the hash stored on the server probably is. |
Slightly ambiguous to me: what will be easier making his own or using a preexisting one?
| chrisname wrote: |
|---|
| You put in your password and the software generates a unique (hopefully) hash. |
As far as I understand hashes there will never be only one piece of input data that will output any specific output data. My logic is as follows: If a hashing algorithm (like SHA-256) allows infinitely large input data and outputs a finite length digest (256-bits in this case) then there will always be an infinite amount of collisions. While they may be hard to find, they exist.
That is what I know, or am I missing something?
Pages: 12