Thursday, December 13, 2012

you really shouldnt let sales people talk about technical products

Authy excited about their new feature:

And the responses at
spindritf 10 hours ago | link

I may be dense but if you back up the tokens and protect that online backup with a password, don't you eliminate the second factor?Now the attacker just needs to get two passwords (to the backup at Authy and to whatever account) so it's reduced to just something you (may) know.
danielpal 10 hours ago | link

Not at all. The attacker would need to get the encryption key and also access to the Authy Backup. Then they also need the password for your account. That said, backups are optional, you can skip them and your account will remain on your phone only.reply
Firehed 10 hours ago | link

How are you encrypting the backups? You recommend a passcode of at least 8 characters, which is only 64 bits. Are you at least running it through some sort of key strengthening algorithm like PBKDF2 to generate the actual encryption key?reply
danielpal 5 hours ago | link

My mistake we are using PBKDF2 already on both iOS and Android.One of the developers added PBKDF2 while doing the implementation. I didn't know exactly how they had implemented the encryption - so I asked to clarify.
So to be completely clear:
1. We use a 256 bit key derived using a salt and PBKDF2.
2. AES is used in CBC mode with a different IV for each account.
3. The key is store on the cellphone only and is never transmitted
danielpal 10 hours ago | link

We're not using PBKDF2. Were using AES-256, we pad the extra bits and use a random IV for each account. However you can enter a 32 character encryption key and you will get a full 256 bit key for encryption.reply
Firehed 10 hours ago | link

Ok, please don't take this the wrong way, but you guys don't seem to know enough about security to be running this kind of service. Being able to access your MFA token from multiple devices defeats the purpose of it being a second factor (since it's must exist only in a single place to be "something you have"), and now you're recommending a backup passcode with less security than WPA2 - a passcode to a backup that by definition should not be allowed to exist.It's bad enough that Google's TOTP keys are too short (80 bits, below the required 128 and recommended 160+), especially given the clarity of the spec and the size of their organization, nevermind being the first large-scale rollout. It's also unfortunate that they half-assed their Authenticator app, which hasn't seen an update in over two years. At least they've had the good sense to improve the workflow of regenerating a token for a new device.I appreciate the problem you're trying to solve and am aware that there tends to be a lot of headache in additional security, but doing this kind of thing provides a false sense of security if not outright lowering the security of what already existed. If I can get access to my MFA tokens by typing in a password, then it's a knowledge factor and not a possession factor. That's one-factor auth with two passwords, like the "security" questions on many banks.
dcu 5 hours ago | link

You don't access the token from multiple devices, just one(your phone).Google's secret keys are weak but Authy's ones are 256 bits.And finally, Daniel was wrong about the key derivation, we are actually using PBKDF2. Sorry for the misunderstanding.
danielpal 9 hours ago | link

We were limited by Google Authenticator usage, so yes, backups are absolutely awful, but it was the only way we saw fit in case you had to upgrade/lost your phone.Now our service Authy and it's Tokens are completely different. If you sign-up to and use our Tokens, those are:
1. Full 256 bits secret seeds.
2. They are never backed-up.
3. Guaranteed to only exist on 1 phone at any given time.
4. We not only regenerate new tokens for new device, we also allow 1 click remote reset of the device tokens.
5. We have a huge number of improvements over Google Authenticator.
7. Tokens are not 6 but 7 digits long.
This version added support for legacy Authenticator Tokens. The existing Authy tokens like CloudFlare, DNSimple etc are not limited to the Google Authenticator addon.
beala 9 hours ago | link

PBKDF2 is a key strengthening algorithm, used to generate a key from a shared secret. AES is a block cipher. I'm not a security expert, but simply padding out the password to the right number of bits seems like a huge no-no. Instead, you should be generating a key of the correct length using something like PBKDF2.Everything I've learned about encryption, I've learned from cperciva. This presentation in particular might be worth your time:
This in particular: "DO: Avoid using passwords whenever possible. DO: Use a key derivation function to convert passwords into keys as soon as possible. DO: Use PBKDF2 if you want to be buzzword-compliant. DO: Use scrypt if you want to be ≈ 2^8 times more secure against serious attackers."
X-Istence 6 hours ago | link

I was looking at Authy, thinking may it could be part of a solution to a problem I was looking to solve for a customer, but this comment right here shows that you and or your company has absolutely no idea what you are doing with crypto and or how to implement it securely and safely.:-(
blake8086 10 hours ago | link

You know those aren't even the same kind of thing, right?reply

No comments:

Post a Comment