3 ms·

There were concerns raised yesterday [1] about the way Authy backs up tokens. The founder's comments initially raised some major flags about their crypto usage

There were concerns raised yesterday [1] about the way Authy backs up tokens. The founder's comments initially raised some major flags about their crypto usage [2], but later on they backtracked and indicated that they are in fact using a logical implementation [3]. The major pro is their seed length, which is significantly longer than Google Authenticator. The major con is you have to trust that they are using a secure system. [1]https://news.ycombinator.com/item?id=4916983 https://news.ycombinator.com/item?id=4916983 [2]https://news.ycombinator.com/item?id=4917283 https://news.ycombinator.com/item?id=4917283 [3]https://news.ycombinator.com/item?id=4917488 https://news.ycombinator.com/item?id=4917488

chimeracoder 14y ago
> The major con is you have to trust that they are using a secure system. From my discussion with the founder on that HackerNews thread yesterday (and his other comments on the thread), it seemed clear that they didn't have a good enough understanding of the space - both the technical security requirements and the existing solutions. If you're not clear on what problem you're trying to solve, I doubt that you understand the domain well enough to solve it properly - at least when it comes to security. Security is one field where 80% of the way isn't "good enough" - in fact, 80% may be worse than nothing at all.
- dcu 14y ago
  Take it easy men, He already stated he was wrong. Do not punish him for wanting to answer fast and be open with the Hacker News community.
  - chimeracoder 14y ago
    > He already stated he was wrong. Do not punish him for wanting to answer fast and be open with the Hacker News community. First, he was way off the mark on a number of unrelated elements, not just the key-strengthening algorithm. While it's good that he owned up to his mistake, it's clear from his wording that he was shaky on the actual principles of security and encryption, not just My standards for a security-sensitive product are far higher than for anything else. Any person in any position of authority should have a very clear understanding of the security fundamentals being used. The last thing I want in a 2FA application is for an overeager PM to make a decision that inadvertently compromises the security of the product, in a well-meaning attempt to improve the UI, branding, monetization, etc.
    - newman314 14y ago
      Exactly. Product design and technical implementations do not happen in separate silos. And I want the security products that I use to inspire a much higher level of trust than some generic tool.
alanctgardner2 14y ago
This looks like it was blown out of proportion. The founder is not involved in day-to-day technical stuff, and he misspoke. It's not the greatest thing to happen to a startup, but it hardly invalidates the whole premise. It's interesting to read that Google's seed length seems to compromise the security of their offering, since most of the replies here seem to be predicated on the idea that Google is doing everything right.
- sweis 14y ago
  The Google Authenticator key length is truncated because of a usability tradeoff. Initially, a design goal was to allow people to manually type in keys on their device. This would be for cases where you couldn't scan a QR code, like when your device has no camera. Given the security setting, I am comfortable with the tradeoff. I do not think brute-force attacks represent a significant risk, especially compared to other attack vectors. That may change over time. Fortunately, it's straightforward to increase the default key size.
- danielpal 14y ago
  This is exactly what happened. Although I am involved in product on 100% of the time, I don't deal with specific implementation details, the engineers working on the solution deal with that. So I tried to be a truthful as possible and answer all the questions I could, I simply got some details wrong. One of the engineers noticed and I rectified my answer.
  - blake8086 14y ago
    I'm not trying to be rude, but they weren't "details", they were the difference between "secure" (which is the service you sell) and "insecure".
    - danielpal 14y ago
      Details are really important. That doesn't mean I could possibly handle every single detail myself, I can't. We have a whole team that handles different parts of the system and they are fully qualified. In fact the engineers doing this feature did write the correct implementation. I simply made a mistake answering the question. I think people are confusing the Authy Google Authenticator Support with the Authy product. We do not sell Google Authenticator or aim to be a replacement for it. We simply added the possibility to add Google Authenticator tokens into the Authy App - mostly since our existing clients wanted this -. Our Service, it's usage etc are completely separate.. If you are not using Authy you can simply use Google Authenticator App. The only thing in common is we both use RFC 6238 which is an open standard for Time based OTP's.

chimeracoder 14y ago

> The major con is you have to trust that they are using a secure system. From my discussion with the founder on that HackerNews thread yesterday (and his other comments on the thread), it seemed clear that they didn't have a good enough understanding of the space - both the technical security requirements and the existing solutions. If you're not clear on what problem you're trying to solve, I doubt that you understand the domain well enough to solve it properly - at least when it comes to security. Security is one field where 80% of the way isn't "good enough" - in fact, 80% may be worse than nothing at all.

dcu 14y ago
Take it easy men, He already stated he was wrong. Do not punish him for wanting to answer fast and be open with the Hacker News community.
- chimeracoder 14y ago
  > He already stated he was wrong. Do not punish him for wanting to answer fast and be open with the Hacker News community. First, he was way off the mark on a number of unrelated elements, not just the key-strengthening algorithm. While it's good that he owned up to his mistake, it's clear from his wording that he was shaky on the actual principles of security and encryption, not just My standards for a security-sensitive product are far higher than for anything else. Any person in any position of authority should have a very clear understanding of the security fundamentals being used. The last thing I want in a 2FA application is for an overeager PM to make a decision that inadvertently compromises the security of the product, in a well-meaning attempt to improve the UI, branding, monetization, etc.
  - newman314 14y ago
    Exactly. Product design and technical implementations do not happen in separate silos. And I want the security products that I use to inspire a much higher level of trust than some generic tool.

alanctgardner2 14y ago

This looks like it was blown out of proportion. The founder is not involved in day-to-day technical stuff, and he misspoke. It's not the greatest thing to happen to a startup, but it hardly invalidates the whole premise. It's interesting to read that Google's seed length seems to compromise the security of their offering, since most of the replies here seem to be predicated on the idea that Google is doing everything right.

sweis 14y ago
The Google Authenticator key length is truncated because of a usability tradeoff. Initially, a design goal was to allow people to manually type in keys on their device. This would be for cases where you couldn't scan a QR code, like when your device has no camera. Given the security setting, I am comfortable with the tradeoff. I do not think brute-force attacks represent a significant risk, especially compared to other attack vectors. That may change over time. Fortunately, it's straightforward to increase the default key size.
danielpal 14y ago
This is exactly what happened. Although I am involved in product on 100% of the time, I don't deal with specific implementation details, the engineers working on the solution deal with that. So I tried to be a truthful as possible and answer all the questions I could, I simply got some details wrong. One of the engineers noticed and I rectified my answer.
- blake8086 14y ago
  I'm not trying to be rude, but they weren't "details", they were the difference between "secure" (which is the service you sell) and "insecure".
  - danielpal 14y ago
    Details are really important. That doesn't mean I could possibly handle every single detail myself, I can't. We have a whole team that handles different parts of the system and they are fully qualified. In fact the engineers doing this feature did write the correct implementation. I simply made a mistake answering the question. I think people are confusing the Authy Google Authenticator Support with the Authy product. We do not sell Google Authenticator or aim to be a replacement for it. We simply added the possibility to add Google Authenticator tokens into the Authy App - mostly since our existing clients wanted this -. Our Service, it's usage etc are completely separate.. If you are not using Authy you can simply use Google Authenticator App. The only thing in common is we both use RFC 6238 which is an open standard for Time based OTP's.