3 ms·

Any device that generates TOTP tokens needs the secret key available by design. Your could read the source code or spec sheets but an easy way to prove this by

• tptacek 10y ago
  For virtually all users, their iPhone is in fact the most secure computing device they own. It's meaningfully more secure than a computer running a desktop operating system. If we're talking about protecting applications running on a desktop OS, the idea of keeping things off the phone because "phones have exploits" is pretty silly; in that threat model, the desktop is also owned up, and with it the email account --- it's now secured solely by a cookie in your Chrome cookie store on your compromised desktop! The threat modeling here just doesn't make sense.
  • lrvick 10y ago
    Yes the desktop is just as bad as the phone. This is why I don't alow any of those devices have secrets that could be used without me being physically present to access data of users I am responsible for, or my own. You are coming at this from a threat profile of joe individual user. Okay, point taken. I am talking about the perspective of trying to take every reasonable step to reamin secure while being targeted by skilled adversaries who have a lot to gain if they succeed. It is not that much extra work to reduce attack surface so much further than TOTP-generator-on-a-phone offers, so why not teach anyone best practices that will listen? Say I have 30+ TOTP secrets in my mobile phone app, and also my password manager. Everyting from Gmail to my AWS root account. If the TOTP secrets are on my phone and an attacker compromises my phone... they get -everything-. If I am using a hardware token for TOTP and I quickly expire the sessions of all really important things I don't log into often, like AWS... then an attacker only gets a slice of the farm instead of the whole thing. What this buys is us is damage control and a much clearer picture of what an attacker could of accessed, and what they probably could not of because no cookies or secrets were available to memory or disk at that time. I can assert -maybe- this one token was phished, but that none of the others were at risk. If the attacker is on a phone with Google Authenticator, they an just generate all the codes they want for every service. We lose the whole farm.
    • tptacek 10y ago
      You keep doing this. I didn't say "desktops are as bad as phones". I said "phones are far better than desktops". I promise you, my security requirements are as stringent as yours are. My 2FA stack is Hardware U2F, Software TOTP, and physically secured backup codes. That's what I recommend. You keep suggesting that this stack is inferior to yours, and I keep explaining why it isn't and why the threat model suggesting to you that it is is incoherent.
      • lrvick 10y ago
        You didn't address my primary point. Say we each have TOTP for say 20 accounts and our password managers on our phones with the credentials for them as well. We are system administrators with access to piles of PII. Account password resets require 2FA so email alone is not enough to spider to other accounts. Both our phones have been rooted and are accessible by a remote attacker because some "coworker" sent us a new beta app that was in fact malware. In both cases the attacker has all our passwords to all apps via our password managers. That is lost. We each are logged into 5 of these services and the attacker steals the cookies. Those are lost. Now what about the remaining 15 services we are not logged into? Things we don't log into super often but some of which ar quite important like AWS root credentials. In your case, the attacker goes and opens the Google Authenticator sqlite database and gets every TOTP secret you have in plain text. You just lost all 15 remaining accounts. In my case those secrets exist on a hardware token and can't be accessed at all. If I catch my intruder at this point I can be reasonably sure those remaining accounts were not impacted. Hopefully this clarifies the wider model I am working from.