texnic wrote:1. I have tried the password recovery using locally stored one-time password. After logging into the system, I was able to read all the secure notes, including those, for which "require password reprompt" was enabled. For a password with this option enabled, this doesn't work, it requires password reprompt indeed. Is it a bug with the notes?
Upon using your password recovery you can now change the password, we kill the reprompt for that and so the password reprompt doesn't really make sense here.
2. On the other hand, if I am using the normal OTPs, in an internet cafe, I don't want to enter my master password. Should I enter another OTP when reprompted?
I think the right thing to do here is not reprompting after a OTP has been used; this point could be argued either way but the reprompt itself is more of a 'casual protection', especially on the website.
3. If my information is encrypted with my master password, how can it be that one-time passwords allow to decrypt it? This forum makes me think that you take the master password, split it into two parts, store one locally and another on your server. Is this correct?
That's a layman's way to explain it -- we do something far more safe, which I'll detail below.
4. Don't you think it makes sense to switch the OTP recovery off by default? I understand why you have created this function and find it rather useful, at least for "normal" users. I should also agree that the implementation, as far as I understand it, is smart indeed. But AES-256 is not the level of encryption for the normal users, it is a military grade algorithm. Therefore the rest of the system should be as robust. Encryption with a strong password with AES-256 is unbreakable. I don't think my email is as secure. Neither can I be sure my laptop won't be stolen. Then this OTP-based recovery becomes a typical backdoor! And false safety in action!
We have to choose the lesser of two issues here -- we scrambled to come up with a password recovery mechanism that exposed nothing to us as an option since a truly shocking number of people forget their master passwords. Given that you can choose to disable the feature entirely, and that the people who will not be remembering their password are far less likely to look at any options I think it's the right choice.
If you do choose to do it, yes your email might not be 100% safe and you rely on the combination of that plus your physical security but it's automatic which is a big requirement on our side. We've thought about expanding this to allow registration of your telephone number and doing an IVR call to it for authorization, especially for people who want to use a random password for their email account.
5. Finally, since the OTPs are 128 bit long, I think you are just saving 128 bits of the master password hash value on your servers and 128 bits locally. Right? If yes, then: Of course, it is impossible to do brute-force attack on your 128 bit since this would require impossible number of connections to your servers. BUT: if your own storage would be compromised, Eve would get my encrypted database and 50% of my master password. 128 bit encryption with AES is still very strong, but it is not AES-256 any more. Taking this into account, wouldn't it be more proper to make OTPs be 256 bit long?
No, that's not how it works at all, and would radically reduce your security with each OTP you made if that was the case. We used 128 bits because that's about the longest reasonable length for people typing in OTPs -- 128bits / 8 bit characters = 16 characters but they could be high ascii so we use 'hex' so 2 hex digits per character = 32 hex digits to type in. That's a stretch already, doing 64 hex digits just seems unreasonable to me.
What we actually do is far more complicated:
- Create a completely random 128-bit number
- Make the random key out of the username and the random password as a hash
- Make a random hash from your username and random password, send this to the server, this will be how we can tell you entered the right 32 digits of hex to allow you to download your encrypted data later
- Encrypt your actual key with the new random_key, so we can retrieve it when random password is entered later, send this to the server
Basically we recursed our entire process using a 128-bit key that's randomly created.
The safety of this is very high, especially if you turn over your OTPs -- a full 128-bit key to encrypted data which gets wiped once you use it.
There is one minor regret here, but it came about because we needed to implement it on a time-line: we're using the same 128-bit OTP process for the stored password recovery hash -- there's no reason that couldn't be 256 bit (or even longer) since you're not typing it in. We'll hopefully get around to fixing this at some point, but 128-bit AES is still exceptionally strong and it would be the end of the universe before it's brute forced .... time is on our side here.