Timeline for How can I improve a password generation scheme based on a shared secret and URL?
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 19, 2011 at 2:20 | history | edited | Jérôme Verstrynge | CC BY-SA 3.0 |
added 303 characters in body
|
| Aug 11, 2011 at 1:33 | comment | added | Nick Johnson | I think you're completely missing the point here. The OP is trying to build a system to generate per-site passwords from a master user password, like SuperGenPass does. He's not asking about password storage on a server. | |
| Aug 10, 2011 at 22:20 | comment | added | Jérôme Verstrynge | @Paulo My point is that you should not only focus on generating hard passwords. But if one only wants a solution this issue, a simple hashing of the user pwd with a public random large number is enough. The result will be a pwd with proper entropy. But again, this is not enough to consider the system secure. | |
| Aug 10, 2011 at 22:05 | comment | added | yogsototh | @diedthreetimes I use this method to generate passwords. Each different for each website, but also easy to remember as I only have to remember only my master password. Which is not possible to do with random password generation. | |
| Aug 10, 2011 at 21:52 | comment | added | Paŭlo Ebermann | This is a nice clarification why you shouldn't do this, but the alternative protocol given here does not really fit the usecase of the original poster - he wanted to generate multiple hard passwords to login to several sites, and have to memorize only one password. | |
| Aug 10, 2011 at 20:44 | comment | added | diedthreetimes | @yogs correct me if I'm wrong but aren't you using the hash as the password for your website? If the hash info was exchanged and visible (unencrypted) what is the question here? | |
| Aug 10, 2011 at 20:13 | history | migrated | from stackoverflow.com (revisions) | ||
| Aug 10, 2011 at 20:01 | comment | added | JVerstry | @diedthreetimes absolutely not, some hash info we will be exchanged and visible between the user device and the server at some stage | |
| Aug 10, 2011 at 19:46 | comment | added | diedthreetimes | collision attacks only apply if an attacker knows the hash they are trying to match (in this case the password). But here the hash is hidden from an attacker. | |
| Aug 10, 2011 at 19:29 | comment | added | JVerstry | @yogsototh See my update in my answer | |
| Aug 10, 2011 at 19:16 | comment | added | yogsototh | How to keep secret the salt in an open source project? The only other way is to make the user choose the salt which seems to be exactly the same than to ask for a longer password. Am I wrong? | |
| Aug 10, 2011 at 19:14 | comment | added | yogsototh | I didn't knew what I wanted to do is called stretching. And from what I read, it is indeed n times (in computer time) more difficult (if I use a good hash algorithm) to crack than the standard hash. | |
| Aug 10, 2011 at 19:12 | comment | added | JVerstry | The random number can be kept secret like the password. It does not have to be public. But even if it was, not using salting makes the work easier for the hacker. See the Practical Cryptography book for more information. | |
| Aug 10, 2011 at 19:08 | comment | added | yogsototh | Of course, someone using this kind of method to generate password is aware that the master password must be very strong. But as the code is open source, salting isn't useful, simply because the salt will be public. I might had problem to explain myself, but for question 2, the attacker should have access to only the sha1(str), not str. | |
| Aug 10, 2011 at 18:48 | history | answered | Jérôme Verstrynge | CC BY-SA 3.0 |