Google Authenticator API - like dragons, for cans
-
@Zecc said in Google Authenticator API - like dragons, for cans:
What kind of weird ass keyboard is that?
?
WFM.
-
@Weng said in Google Authenticator API - like dragons, for cans:
2FA either needs to be transferrable between devices, trivially resettable, or not tethered to a very fragile device. And yes, both of the first two severely weaken actual security.
It does not need to be trivially resettable. It needs to be resettable in some way, but that should involve yet another way of verifying your identity.
SMS used to be a good option as the operator will generally try to verify your identity before handing out a replacement SIM, but no longer since adding an app that will silently read a SMS is rather trivial. My online banking now has a mechanism where the authenticator app can be transferred either with the old device, or by walking up to an ATM and authenticating with the debit card, which is reasonable, since they can ensure physical security of the ATMs (all have surveillance cameras these days). But for general services, there don't seem to be other externally-authenticated tokens beyond the phone number.
-
Hm. Damn, this thread just reminded me that I used to have a Google Authenticator set up for the account that owns a Discord server I used to run that I never deleted, and that authenticator didn't transfer to my new phone.
-
@Zecc said in Google Authenticator API - like dragons, for cans:
weird ass-keyboard
I won't link the Rosie, but yeah
-
@Jaloopa said in Google Authenticator API - like dragons, for cans:
@Zecc said in Google Authenticator API - like dragons, for cans:
weird ass-keyboard
I won't link the Rosie, but yeah
FINALLY.
-
@Parody said in Google Authenticator API - like dragons, for cans:
There are a couple of plugins for KeePass for Windows that give OTP functionality, in both the "you must provide an OTP from somewhere else to open the database" ...
What exactly does that protect the database from?
I did some searching to see if my new security key could be used to add 2FA to my KeePass database and by end of that I was convinced that having OTP in KeePass (or for any static file) makes no sense. For example, if OTP changes after each use, then the static file must be re-encrypted with the next OTP to be able to open it next time. However, if a bad guy has an older copy of the file then the previous OTP that was used to open the file would be forever usable, which defeats the purpose of a one time password.
The closest (and possibly best) idea that I can think of is to use the GPG key on my security device (along with a password) to encrypt the database. That creates a 2-factor system because the security device never discloses its GPG key and needs to be present to open the file, but this is not an OTP.
-
@quijibo And then the database is vulnerable once it has been copied out. Would be safer to keep it in the device permanently, but that would make it quite hard to check if the device was actually secure - a leyperson wouldn't know the difference between a secure version of such a device, and one that did not do any encryption at all just storing the passwords in plaintext on some flash. But the latter device would be much cheaper.
-
@PleegWat Yes, I agree that storing passwords on a dedicated security device would be better. However, my assumption is that my home PC is secure enough to work with the unencrypted data. (If that was not the case then there are other larger issues like how to set up the password database securely in the first place.)
Rather, my idea was to protect against someone with a copy of the encrypted file from brute forcing the master password. Requiring a 2048-bit GPG key along with an "okay" master password accomplishes that as long as I have the security device with the GPG key with me.
-
@Weng said in Google Authenticator API - like dragons, for cans:
@blakeyrat said in Google Authenticator API - like dragons, for cans:
@Weng said in Google Authenticator API - like dragons, for cans:
fully potted
I didn't pot mine, I put it on a keychain.
Was I supposed to bury it next to the tomato plant?
Fully potted as in "all the electronics are encased in a solid block of epoxy".
The IT security crowd and opensource folk like to interpret potted boards as an attempt at security by obscurity because it makes it really hard to take them apart and see how they work without destroying them.
But it's really a durability thing, because it utterly prevents components from moving relative to each other, and prevents contamination from water, dust, etc.
And the epoxy itself is super tough and therefore very protective.
And some (but not necessarily all) devices protected like this will have a wire mesh embedded in the epoxy, and a circuit in the device that can permanently brick the device and nuke any crypto parts if the wire mesh is broken, like if someone tries to break through the epoxy to get at the chips inside.
-
@quijibo said in Google Authenticator API - like dragons, for cans:
@Parody said in Google Authenticator API - like dragons, for cans:
There are a couple of plugins for KeePass for Windows that give OTP functionality, in both the "you must provide an OTP from somewhere else to open the database" ...
What exactly does that protect the database from?
My guess is that it helps protect the authors from people who bug them about having OTP logins.
-
@Steve_The_Cynic said in Google Authenticator API - like dragons, for cans:
And some (but not necessarily all) devices protected like this will have a wire mesh embedded in the epoxy, and a circuit in the device that can permanently brick the device and nuke any crypto parts if the wire mesh is broken, like if someone tries to break through the epoxy to get at the chips inside.
That, and secure chips typically have embedded gotchas such as:
- nanometric meshes covering the active layers
- temperature sensors
- light sensors
- voltage supervisors
- clock speed supervisors
- other stuff manufacturers don't talk about publicly
Trip any of those, and you can wave your crypto data goodbye.
They also include passive defenses against side-channel attacks (like power/RF analysis) and optical inspection (structures that look like standard elements, but aren't).
-
@Zerosquare said in Google Authenticator API - like dragons, for cans:
@Steve_The_Cynic said in Google Authenticator API - like dragons, for cans:
And some (but not necessarily all) devices protected like this will have a wire mesh embedded in the epoxy, and a circuit in the device that can permanently brick the device and nuke any crypto parts if the wire mesh is broken, like if someone tries to break through the epoxy to get at the chips inside.
That, and secure chips typically have embedded gotchas such as:
- nanometric meshes covering the active layers
- temperature sensors
- light sensors
- voltage supervisors
- clock speed supervisors
- other stuff manufacturers don't talk about publicly
Trip any of those, and you can wave your crypto data goodbye.
They also include passive defenses against side-channel attacks (like power/RF analysis) and optical inspection (structures that look like standard elements, but aren't).
I'd worry about some of those being tripped by power surges or dropping the damn thing.
-
@ben_lubar so you can assume you could probably get away with tripping one at a time, maybe.
-
@quijibo said in Google Authenticator API - like dragons, for cans:
@Parody said in Google Authenticator API - like dragons, for cans:
There are a couple of plugins for KeePass for Windows that give OTP functionality, in both the "you must provide an OTP from somewhere else to open the database" ...
What exactly does that protect the database from?
I did some searching to see if my new security key could be used to add 2FA to my KeePass database and by end of that I was convinced that having OTP in KeePass (or for any static file) makes no sense. For example, if OTP changes after each use, then the static file must be re-encrypted with the next OTP to be able to open it next time. However, if a bad guy has an older copy of the file then the previous OTP that was used to open the file would be forever usable, which defeats the purpose of a one time password.
The closest (and possibly best) idea that I can think of is to use the GPG key on my security device (along with a password) to encrypt the database. That creates a 2-factor system because the security device never discloses its GPG key and needs to be present to open the file, but this is not an OTP.
Indeed, OTPs only really work for remote services where the attacker can't read the full state nor modify it.
All other stuff is just fluff if we're talking about local password files. Though encrypting on your other device still has the risk that somebody intercepts your plain database right before encryption.
EDIT: Those OTP plugins could work though if the OTP is checked in some remote service after which it will return part of the password DB's encryption key. Then your password DB doesn't need to be mutable, and the OTP service doesn't need to know the complete encryption key ( even a salt-like value will do).
You then have to wonder though if you can trust the OTP service with regards to security and uptime.
-
@ben_lubar said in Google Authenticator API - like dragons, for cans:
I'd worry about some of those being tripped by power surges or dropping the damn thing.
I wouldn't worry too much about it. If the credit/debit card in your wallet has a chip on it, it almost certainly includes those security measures (and probably others). Yet those cards very rarely fail.
-
@Zerosquare said in Google Authenticator API - like dragons, for cans:
it almost certainly includes those security measures
You say this as if you don't have an involuntary twitch whenever someone claims to have bank-grade security.
-
@Zerosquare said in Google Authenticator API - like dragons, for cans:
(structures that look like standard elements, but aren't)
That is some advanced chemistry there.
