There are so many of these. I don't discourage building one for fun, but they're usually not practical.
The common problems are password resets, different password restrictions/formats, and the need to remember these.
Also... Sha256 for password generation? I've been told that's wrong™, even if you do it a lot of times, and was pointed at key derivation functions like scrypt, bcrypt, etc.
Nadya already mentioned the problem of having a common password, but I think that's actually not such a big problem here, as you do some checks to make sure "123456" doesn't pass.
As I can see from "salty", you know that applying a hash function once or twice is not a good way to store a password (even in a hashed form).
Now, you're applying that hash function a lot more often than once or twice, but that still only takes a fraction of a second.
Quoting the "hashlib" documentation:
Key derivation and key stretching algorithms are
designed for secure password hashing. Naive algorithms
such as sha1(password) are not resistant against
brute-force attacks. A good password hashing function
must be tunable, slow, and include a salt.
Your approach is not too tunable, in the sense that you can't configure its memory usage, only the time it takes.
What if your attacker just throws more money at the problem? Sha256 has been shown to be feasible to implement in hardware, and that fraction of a second will melt away, partly possible because not much memory is consumed.
And then there is the well-known advice to not roll your own crypto. In this case, that means using a well-known key derivation function that's meant to be used in scenarios like this, instead of using your custom method with a "I think this is safe enough" attitude. Personally, I'd have a little more confidence in something that says "uses scrypt", simply because I know that name and that it's suitable for this application. It can still be used wrong, but I wouldn't feel compelled to check if you rolled something yourself. :)
Lastly, I'm saying all this because I made one of these things myself, which used a dangerously custom method of seeding a "cryptographically strong" Sha1 PRNG for password generation. Yes, that bad.
1) The encrypted data can be lost, thereby locking the user out of all of their accounts.
2) The encrypted data can be stolen. If the user was using a weak master password, all of their accounts can be compromised.
3) The data can only be synced to a limited number of devices.
1) Backups. Never only keep 1 copy of something you can lose. And to be even more secure: never keep backups in the same place (both at home? what if your house burns down?) This one is plausible but not the largest of concerns, IMO.
2) User error. This is the most plausible attack but Visionary is worse in this regard. I'll expand on this below.
3) Depends what program you use. Or whether you take advantage of syncing to begin with (I personally don't.)
Since Visionary always returns the same password for a given Master password - it becomes security by obscurity. If you're going to make the lines of Argument #2, if a user uses a common Master password and a hacker bruteforces passwords through Visionary using common passwords - they will obtain the supposedly more secure password. But if a person uses an insecure password on a "standard" password manager that generates them a random password - that sort of attack becomes impossible unless they get their hands on the user's database.
I'm going to be honest: the attack vector I'm most concerned about (#2) as it is also the most plausible threat to potential security: Visionary is less secure because it always generates the same password from anywhere. Meaning anyone with a weak password is more "at-risk" because most people aren't going to have their database stolen, let alone by someone who'd know what to do with it or furthermore would even bother with it. They'd spend less time stealing another laptop than working through an encrypted one.
I know client side security is a joke, but the only reason I made it iterate thousands of times is to increase the time taken to generate a password. That makes brute force attacks unfeasible.
9 comments
[ 2.7 ms ] story [ 35.4 ms ] threadThe common problems are password resets, different password restrictions/formats, and the need to remember these.
Also... Sha256 for password generation? I've been told that's wrong™, even if you do it a lot of times, and was pointed at key derivation functions like scrypt, bcrypt, etc.
One of those articles, but there may be better or more correct ones: http://www.justgohome.co.uk/blog/2014/02/salting-hashing-and...
As I can see from "salty", you know that applying a hash function once or twice is not a good way to store a password (even in a hashed form).
Now, you're applying that hash function a lot more often than once or twice, but that still only takes a fraction of a second.
Quoting the "hashlib" documentation:
Your approach is not too tunable, in the sense that you can't configure its memory usage, only the time it takes.What if your attacker just throws more money at the problem? Sha256 has been shown to be feasible to implement in hardware, and that fraction of a second will melt away, partly possible because not much memory is consumed.
And then there is the well-known advice to not roll your own crypto. In this case, that means using a well-known key derivation function that's meant to be used in scenarios like this, instead of using your custom method with a "I think this is safe enough" attitude. Personally, I'd have a little more confidence in something that says "uses scrypt", simply because I know that name and that it's suitable for this application. It can still be used wrong, but I wouldn't feel compelled to check if you rolled something yourself. :)
Also check: http://security.stackexchange.com/questions/211/how-to-secur...
Lastly, I'm saying all this because I made one of these things myself, which used a dangerously custom method of seeding a "cryptographically strong" Sha1 PRNG for password generation. Yes, that bad.
If I said anything wrong, please correct me.
2) The encrypted data can be stolen. If the user was using a weak master password, all of their accounts can be compromised.
3) The data can only be synced to a limited number of devices.
1) Backups. Never only keep 1 copy of something you can lose. And to be even more secure: never keep backups in the same place (both at home? what if your house burns down?) This one is plausible but not the largest of concerns, IMO.
2) User error. This is the most plausible attack but Visionary is worse in this regard. I'll expand on this below.
3) Depends what program you use. Or whether you take advantage of syncing to begin with (I personally don't.)
Since Visionary always returns the same password for a given Master password - it becomes security by obscurity. If you're going to make the lines of Argument #2, if a user uses a common Master password and a hacker bruteforces passwords through Visionary using common passwords - they will obtain the supposedly more secure password. But if a person uses an insecure password on a "standard" password manager that generates them a random password - that sort of attack becomes impossible unless they get their hands on the user's database.
I'm going to be honest: the attack vector I'm most concerned about (#2) as it is also the most plausible threat to potential security: Visionary is less secure because it always generates the same password from anywhere. Meaning anyone with a weak password is more "at-risk" because most people aren't going to have their database stolen, let alone by someone who'd know what to do with it or furthermore would even bother with it. They'd spend less time stealing another laptop than working through an encrypted one.