
A smarter kind of password manager - libeclipse
https://github.com/libeclipse/visionary
======
Nadya
_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.

~~~
libeclipse
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.

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

~~~
libeclipse
Why is it wrong?

~~~
tilpner
I'd embarass myself if I tried to explain this with the correct terms, so I
won't try.

One of those articles, but there may be better or more correct ones:
[http://www.justgohome.co.uk/blog/2014/02/salting-hashing-
and...](http://www.justgohome.co.uk/blog/2014/02/salting-hashing-and-key-
derivation.html)

~~~
libeclipse
Visionary doesn't try to store passwords securely. I'm not sure how that
article is relevant, but maybe I'm missing something. Care to elaborate?

~~~
tilpner
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. :)

Also check: [http://security.stackexchange.com/questions/211/how-to-
secur...](http://security.stackexchange.com/questions/211/how-to-securely-
hash-passwords/31846#31846)

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.

~~~
libeclipse
Thanks for the constructive feedback mate. I'm considering implementing pbkdf2
and using that instead of sha256. Thoughts?

~~~
libeclipse
Actually I think I'm going to go with Scrypt. Just looking at my key
generation code now, and it looks childish and terrible.

