Before I even started this, I actually updated the systems we have in place for managing password hashes to move to the password competition winner Argon2. It updates the hash on next login to our various systems.
However, a big step forward would be two factor authentication where in addition to a username and a password we ask for an extra bit of information.
From various research the way to do this is using TOTP (which is a timed OTP using OATH hashing system). Basically you have an app or device that provides a code every so often, and when you log in you have to enter the current code. We are using the default of 6 digit codes created ever 30 seconds.
There are quite a few issues with this, and a scarily large number of OTP and OATH and TOTP applications available. It is a well published standard.
The challenge is getting the "seed" or "key" in to the device, or if it is a hardware device, then from the device to us. The latter is something to tackle later as most people use a mobile app these days, so we make the seed/key and it has to get in to the app.
The answer is a QR coded URI and there is a "standard" for this. It encodes the settings in a standard format with the seed/key in BASE32 which can be read by various apps including Google Authenticator. Once read, it provides a code every 30 seconds.
At our end we need to store the seed, which ultimately has to be readable. But we have hash for password and a readable OTP seed, so two factors, which is a good start. There is no real way around storing the seed in a readable format, sadly.
But it does get quite complex, and this is what I am working through now.
1. How do you make sure setting up or resetting the TOTP is safe / authenticated. Current plan is texting a code as an alternative two factor authentication before we can disclose the seed/key as a QR code. Some actions need to be properly two factor authenticated.
2. Do we allow changes of password if not already TFA, and what of lost password - is that independent?
3. What access do staff have to reset or clear the TFA system? How do we defend against social engineering whilst not locking out genuine customers? How much staff training on social engineering can we do? Ho much staff time will this take?
4. What levels of control do we offer to customers, what degrees of paranoia do we support?
5. What of ancillary systems such as ordering or the CHAOS2 API? Current plan is ordering will require the TOTP code if that is set up at all, even if normal logins not requiring as "trusted browser".
It is never as simple as it sounds when looking purely at the technical side. Systems like this extend in to social engineering!
Anyway, we are starting with staff logins, and then moving to end user logins on our various systems offering, and even recommending, two factor authentication.
P.S. Yes I waited more than 5 minutes after taking that picture so that even if you know my username and password you cannot use the code. And yes, we also protect against replay attacks on the code.
P.P.S. After some feedback we now only show the QR code until the installation has been confirmed, then it is no longer shown. That means the SMS codes and the authenticator codes use different seeds so we can tell which was used (and check for a clash just in case). Thanks for the feedback, this helps security.
If you are implementing 2FA with the Google Authenticator compatible stuff, please let people have the option for the device to prompt as well as the code based response.
ReplyDeleteI use this a lot at work, our VPN is 2FA as is O365 access. Both set to prompt on my phone. I like it. Amazon annoys me slightly as I had to signup to it in the states, because apparently here in the UK we're not worthy of 2FA, and they make me use the code only. Ripe use code only.
Paypal 2FA is annoying, they insist on texting me a code which I don't think is as secure.
Not quite sure what you mean? Is that challenge/response stuff?
DeleteYes, it may well be, I don't know how it works - just that I get a prompt on my phone to approve to deny the login for the given service. It's dead handy.
DeleteWhile it's not commonly known, and it's massively fiddly and time consuming to set up, it /is/ actually possible to use standard TOTP with paypal & ebay
DeleteAny links on how to accomplish this..
Delete[While it's not commonly known, and it's massively fiddly and time consuming to set up, it /is/ actually possible to use standard TOTP with paypal & ebay]
Short answer, use the script at https://github.com/cyrozap/python-vipaccess to generate a otpauth string. Note the serial number (something like VSST18455234) and the secret (something like WBH53V4SVGAZFJYXK7HFDEWB6K3L767P).
DeleteThen go to PayPal and turn on 2FA using the option for a Symantec VIP token. When asked for the token serial number enter the serial number from above (e.g VSST18455234). Then just use the secret to set up an account in your favourite TOTP app.
This works because behind the scenes Symantec VIP uses TOTP. The script uses the Symantec API to generate a new token and reverse engineer it to get the secret.
Nice, I'd like to see Multi Factor auth with AAISP services. I already use Google Authenticator with Amazon, Lastpass, Linux Logins etc.
ReplyDeleteIn my experience:
1. Initial setup is based on the user's password so the multi factor setup is only as secure as that login. If a user wants to reset the multifactor it means unregistering the old device (either using a current code from the device or an “emergency” one time code provided during the registration) then registering the new device as normal.
2. Interesting one, idea is you should know something and have something. If you “know” enough to reset the password then “having” the device with the token on it isn’t really helping or hindering you.
3. Doesn’t this apply now anyway? If a staff member allows a reset today what damage can this really do? Will broadcasting the reset to the registered email/mobile numbers be enough to catch fraudulent resets?
4. Login logs? Not sure what else you can show.
5. Assume you're thinking about setting cookies on "trusted devices" here. Getting it working on day to day systems like clueless without this would be a good start. Can learn lessons then worry about other order systems etc tomorrow.
Initial set up is a tricky one - current plan is using SMS as extra check on setting up TOTP (after normal password login). That way we have used email (for password) and SMS.
DeleteWhat was the old password hashing method? :)
ReplyDeleteRE: My answers
1) On setup of TOTP make sure the user is authenticated with username and password as normal. Maybe from a trusted IP as well.
2) I would keep them separate
3) Tricky question. Maybe offer an option for "I know what I'm doing" with backup codes and what not but it's a difficult balance for sure.
4) See above
5) I don't know what the CHAOS2 API is, so N/A.
Just to add that NIST no longer recommend the use of SMS for 2FA
ReplyDeletehttps://www.schneier.com/blog/archives/2016/08/nist_is_no_long.html
It's taken PayPal this long to get SMS as a 2FA, wish they'd read that!
Deleteplease make it possible to do some basic operations on chaos (e.g. get the quota) without having to store my control username/password in a file!
ReplyDeleteIndeed, I am planning to allow a lot of things on CHAOS without the authenticator. Needs to be worked out carefully. But the ordering side will want it.
DeletePersonally I find 2FA a pain. I inevitably end up somewhere where I don't have my iPad, forgot my phone for SMS (I don't like the huge size of smartphones), the iPad battery is flat or can't get network access, I don't have the silly card reader the bank sent me through the post or whatever. I can remember the username/password login to whatever service it is I'm trying to use, but I can't do a damn thing because I don't have the 2FA working. If I'm on holiday and can't fix things for two weeks then I'm in big trouble. I alread have two things I have to carry for 2FA on various different services, where will it end? An extra bag to carry all the 2FA devices? Now which card reader was it again for this bank account?
ReplyDeleteThen don't set up 2FA! However, network access on the 2FA device is not needed for this to work - it is standalone. It can also be installed on more than one device (iPhone and iPad for example). It is a common system used by may sites so can be one device (or two for redundancy) for many systems that use 2FA like this.
DeleteSo you don't consider the proliferation of different 2FA schemes and devices to be a problem then? At present I need my phone for SMS for one bank, and a dedicated debit card device for another bank. If I use your 2FA service add to that my iPad. In your case I don't have to set it up, but for online banking it's mandatory for certain actions like paying a new person.
DeleteRevK is proposing using a scheme that is already widely used. One I already have 6 accounts registered with on my phone (which is all within the one application). If anything IMHO, this is the wise choice, rather than a new system, application, or some other physical object.
DeleteThere is always a choice between security and convenience, for my banks and other systems that deal with money & my email (which are the "keys to the kingdom" for so many services) I choose security over convenience!
FWIW, with TOTP, I have Facebook, Google, Github and other services all using a single authenticator app.
DeleteBasically, everything other than banking does TOTP; banking insists on you using their non-standard apps.
The authy app can synchronise your TOTP codes between devices, including pc and (I think) Mac.
DeleteHave you looked at U2F? I'm using it perfectly well with FastMail:
ReplyDeletehttps://blog.fastmail.com/2016/07/23/how-u2f-security-keys-work/
I've been using yubikeys for some time now for a number of services, some use U2F, some the original OTP and have also played worth OATH and certificates on them, very versatile little device.
ReplyDeleteAnother fan of Yubikeys here. We use them to control access to production servers, among other things.
DeleteUnfortunately the system A&A have set up appears to require that the code be SMSed to you, which... doesn't work so well if you're outside mobile phone coverage (or just don't have one: so I can't test it, since my phone is extremely kaput and I have such bad coverage there is no point replacing it). If they could just display it, I believe the yubioath command-line tool could get the yubikey to do all the work for you, keeping the secret code part of OATH properly secret. If they could just display it... sure, this doesn't verify that you possess the specified mobile phone, but it *does* verify that you possess the device on which you entered the initial OATH secret, which is effectively equivalent.
DeleteWe text you a code initially, but once you manage that you install in an app or device. I am sure getting a mobile to work once it not impossible.
DeleteAh, right. Strange way to go about it, given that the mobile phone number is no more securely provided than the auth to the system you're asking to send you the code.
DeleteLet's see if it works with yubioath then! (What's the worst that could happNO CARRIER
So I hit 'send a code' (presumably something done only once, following which it is time-based), and got, uh, an internal server error page, and no code: .
DeleteThis was at about 17:19:50 2016-12-06, if that helps you dig around in your logs.
It is just an extra step...
DeleteRight in the middle of me improving the messaging and making a typo my side, try again, sorry.
Delete"SMS failed to send", it said... and then the SMS arrived. :) it contained a whole bunch of empty unknown-glyph squares followed by the code. :)
DeleteWith that entered, I can confirm that your setup is yubioath-capable: my Yubikey Neo's quite happy to keep hold of the shared secret for me and the desktop authenticator generates TOTPs from that on demand, and they work to log in with.
Yeh I am improving it now. We are trying to not have the code shown on the lock screen of phones.
DeleteGood decision (and it worked, all I could see at first was squares, and oh look another bug, I thought. Not so.)
DeleteThe QR-code stuff was nicely done: yubioath-desktop could auto-scan it easily and the code beneath corresponded to it and was cut-and-pasteable. It would presumably work fine on an Android phone too (Neos have NFC capabilities so can serve as a secure keystore if you have an NFC-capable phone as well).
The multiple, customizable levels of paranoia are nice to see. I do wonder how many people will pick the highest and lowest levels, given that people don't like to be locked out if they lose their phone but also probably want more than a trivial level of added security or they wouldn't have set up 2FA at all :)
The barcode is also clickable as an href and works on some phones to go to an installed authenticator app if doing this on a phone. So many subtleties to this whole process. Still considering not showing QR code once installed. We also tested where we manually put in a seen for a physical device, and that is a case I need to hide the QR code/etc obviously.
DeleteNo longer squares, just lots of text and newlines... Should work.
DeleteOne of my more painful sides of 2FA is when it comes to changing your device. There are umpteen different way it's done, some nice transitions, others are more painful where the only way to do it is to disable 2FA and then re-enable it. Several sites have the option for backup codes to be saved for when you don't have access to your normal 2FA device.
ReplyDeleteAuthy app
DeleteWe use a RAC card for our work 2fa. It's a credit card sized grid of letters and numbers 10 x 5. Each person receives a unique card stamped with a serial number. When connecting via vpn the software prompts users network logon and then for 3 grid references from the serial numbered card. The card can be physical or an image (mine is both) that gets allocated to the users account. We used to use token generator devices but in the interest of cost saving (40000 employees) this was deemed secure enough (and we're a healthcare provider).
ReplyDeleteIs it just me that doesn't really buy that these TOTP based software authenticators are really 2FA?
ReplyDeleteI mean, as long as you know the initialisation code (the thing encoded in the QR barcode) then you can work out the current code and get acccess - so this is just a second example of "something you know" in addition to your password, rather than a true 2FA solution which requires "something you have".
This is quite different to what something like RSA SecurID offers where a true physical token that cannot be copied or duplicated is used.
(Not suggesting it's not a useful tool to enhance security, but it really is not two-factor authentication).
It is same as rsa key just that you never saw the seed that is in the key. That is a price for using mobile phone apps. But I see your point.
Delete"I mean, as long as you know the initialisation code (the thing encoded in the QR barcode) then you can work out the current code and get acccess"
DeleteThis applies to the SecureID tokens too, the difference is that it's difficult to get the key out of them, perhaps even impossible by the hardware design. The protection of this key is a matter of implentation, and each solution will have strengths and weaknesses.
RSA token is physically robust and tamper-resistant. Google Authenticator is reliant on the device, it may use the filesystem which may be encrypted or it may use a hardware enclave. I use a SQLCipher encrypted SQLite database on an encrypted iPhone with a PIN, so my storage of the keys are arguably as secure as the RSA token, even more so when you consider that, unlike an RSA token, mere posession of the device doesn't permit you to see the 6-sigit code and requires another layer of knowledge on top again.
So yes the app-based approaches are proper two-factor implementations, and individuals must assess whether the implementation, and the device on which that implementation resides, meets their individual security challenges.
The seed key should ideally not be made available again on the server side, which RevK's implentation does, but the attacks against an A&A account to see it imply you would already have access and could therefore reset it anyway, so probably not an issue.
Indeed, another convenience trade off, I felt useful to allow install on second device. It may be worth changing that or making it harder at least. Something to consider.
DeleteI'd call it an essential component of two-factor security. It's up to the user if she wants to go the extra step of paranoia and go from "a thing I have but which can probably be copied by someone with enough skill, i.e. my phone" to "a thing I have which is tamper-proof, i.e. a secure token capable of OATHery". A&A can't tell: all they can tell is that the protocol is being carried out by some remote wossname which shares the key. They can't tell how securely the key is stored. (In practice, most phones have secure tamperproof storage on board now that is used by things like Google Authenticator to store its secrets.)
DeleteObviously, if the shared secret is stolen, all is lost, but that just means you should keep it secure: that just means that at the initialization stage, you have "something you know", but unless you have a very good memory you stick it in the authenticator app and it then becomes "something you have", following which you "just" have to make sure your phone isn't stolen and keep it locked when not in use. (In practice, people losing their phones often seems to have the same emotional effect on them as losing a child, so maybe a random phone is sufficiently secure even absent extra security in that area.)
Myself I keep my Yubikey on my keyring, so anyone who steals my front door keys can log in to A&A, gaining them the right to manipulate the same ADSL line they have physical access to because they stole my front door keys. They can also log into my computers, which they *also* have physical access to for the same reason. Good thing they probably don't know where I live... I believe the visible A&A billing data includes the address to which my front-door key is tied. This won't help them either, because they don't know my A&A account number so they can't authenticate there either. Not that they have any way to tell I'm even an A&A customer.
Phew. I think it all still hangs together.