16 ms·
This is pretty incredible. These aren't just good practices, they're the fairly bleeding edge best practices. 1. No more SMS and TOTP. FIDO2 tokens only. 2. N
by staticassertion 5y ago
This is pretty incredible. These aren't just good practices, they're the fairly bleeding edge best practices.
1. No more SMS and TOTP. FIDO2 tokens only.
2. No more unencrypted network traffic - including DNS, which is such a recent development and they're mandating it. Incredible.
3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edge - almost no one does that today.
My hope is that this makes things more accessible. We do all of this today at my company, except where we can't - for example, a lot of our vendors don't offer FIDO2 2FA or webauthn, so we're stuck with TOTP.
- suns 5y agoYea, imagine the implications of federal agencies all implementing this successfully. Can't wait to see what the trickle down(?) effect is.
- EthanHeilman 5y agoWe've been building to these goals at bastionzero so I've been living it everyday, but I feels validating and also really strange to see the federal government actually get it.
- meepmorp 5y agoAlso, “Password policies must not require use of special characters or regular rotation.” They even call out the fact that it's a proven bad practice that leads to weaker passwords - and such policies must be gone from government systems in 1 year from publication of the memo. It's delightful.
- CGamesPlay 5y agoI am a bit concerned that this will be read as "Password policies must require the use of no special characters", possibly as a misguided attempt to push people away from adding using "Password123!" as the password. I wish the memo had spelled out a little more clearly that there's nothing wrong with special characters, but they shouldn't be required. Also, is a whitespace a special character?
- pm90 5y agoIf we were to stop using special characters and only use human friendly phrases (eg “jupiterIsTheSmallestPlanet”) it wouldn’t be the end of the world.
- godelski 5y agoBut if a whitespace is not a special character (or punctuation) we can add entropy with "Jupiter is the smallest planet!" while still being human readable and using the passphrase paradigm.
- atuladhar 5y agoSomewhat unrelated, but hopefully this also means TreasuryDirect will get rid of its archaic graphical keyboard that disables the usage of password managers. (Graphical keyboards are an old technique to try to defeat key loggers. A frequent side effect of a site using a graphical keyboard is that the developer has to make the password input field un-editable directly, which prevents password managers from working, unless you use a user script to make the field editable again.)
- tbirdz 5y agoJust saying in this in case it will help you. For treasurydirect, you can use inspect element and change the value="" field on the password element, and paste in your password from your password manager. It's not as convenient as autofill from your password manager, but it sure beats using the graphical keyboard.
- pitaj 5y agoWhat's wrong with TOTP?
- Sesse__ 5y agoIt authenticates the user to the service, but not the service to the user, so it's vulnerable to phishing (or MITM, of course, if you don't have TLS).
- jaycroft 5y agoI was wondering the same thing - here's an article I found that describes both approaches. Not being in the cryptography space myself I can't comment on how accurate it is, but passes my engineering smell test. https://blog.trezor.io/why-you-should-never-use-google-authenticator-again-e166d09d4324 https://blog.trezor.io/why-you-should-never-use-google-authe... Edit - sorry that this is really an ad for the writer's products. On the other hand, there's a hell of a bounty for proving them insecure / untrustworthy, whatever your feelings on "the other crypto".
- deleted 5y ago[deleted]
- tptacek 5y agoYeah these are very dumb arguments against TOTP.
- deleted 5y ago[deleted]
- tptacek 5y agoIt's very phishable. Attackers will send text messages to your users saying "Hi, this is Steve with the FooCorp Security Team; we're sorry for the inconvenience, but we're verifying everyone's authentication. Can you please reply with the code on your phone?" It's even worse with texted codes because it's inherently credible in the moment because the message knows something you feel it shouldn't --- that you just got a 2FA code. You have to deeply understand how authentication systems work to catch why the message is suspicious. You can't fix the problem with user education, because interacting with your application is almost always less than 1% of the mental energy your users spend doing their job, and they're simply not going to pay attention.
- c0l0 5y agoI think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service. Banks and media corporations are doing it today by requiring a vendor-sanctioned Android build/firmware image, attested and allowlisted by Google's SafetyNet (https://developers.google.com/android/reference/com/google/android/gms/safetynet/SafetyNet https://developers.google.com/android/reference/com/google/a...), and it will only get worse from here. Remote attestation really is killing practical software freedom.
- seibelj 5y agoReproducible builds are a thing, I don't know how widespread they are. I know the monero project has that built in so everyone compiles the exact same executable regardless of environment, and can verify the hash against the official version https://github.com/monero-project/monero https://github.com/monero-project/monero
- nybble41 5y agoReproducible builds allow the user of the software to verify the version that they are using or installing. They do not, by themselves, allow the sort of remote attestation which would permit a service to verify the context for authentication—the user, or a malicious actor, could simply modify the device to lie about the software being run. Secure attestation about device state requires something akin to Secure Boot (with a TPM), and in the context of a BYOD environment precludes the device owner having full control of their own hardware. Obviously this is not an issue if the organization only permits access to its services from devices it owns, but no organization should have that level of control over devices owned by employees, vendors, customers, or anyone else who requires access to the organization's services.
- InitialLastName 5y ago
- dc-programmer 5y agoFor anyone interested in 3, Google’s BeyondCorp whitepapers are an excellent starting point
- vmception 5y agoForce banks to do this, immediately. They can levy it on any organization with a banking license or wants access to FEDWire or the ACH system. Force it for SWIFT access too, if the bank has an online banking system for users.
- criddell 5y agoI asked my bank about their 16 character limit on password length because it suggests they are saving the password rather than some kind of hash. Their response - don't worry about it, you aren't responsible for fraud. Banks aren't going to want to implement any changes that cost more (in system changes and customer support) than the fraud they prevent.
- nextos 5y ago> 1. No more SMS and TOTP. FIDO2 tokens only. SMS are bad due to MITM and SIM cloning. In EU many banks still use smsTAN, and it leads to lots of security breaches. It's frustrating some don't offer any alternatives. However, is FIDO2 better than chipTAN or similar? I like simple airgapped 2FAs, but I'm not an expert.
- tptacek 5y agoThe major advantage of FIDO2 is that it's difficult to phish. SIM cloning is not the primary reason organizations are now advocating against SMS 2FA.
- tialaramex 5y agoIn particular [Thomas knows this, for anybody else reading], WebAuthn (the way you use FIDO for the web, U2F is a legacy system for doing the same thing that you should not use in greenfield deployments) recruits your web browser to defeat phishing. When you use WebAuthn to sign into an site the browser takes responsibility for determining which site you're on, cutting out the whole phishing problem of "Humans don't know which site it is". The browser isn't reading that GIF that says "Real Bank Secure Login" at the top of the page or the title "Real Bank - Authenticate" or the part of the URL bar that says "/cgi-bin/login/secure/realbank/" it is looking only at the hostname it just verified for TLS which says fakebank.example So the browser tells your FIDO authenticator OK, we're signing in to fakebank.example - and that's never going to successfully steal your Real Bank credentials because the correct name is cryptographically necessary for the credentials to work. This is so effective crooks aren't likely to even bother attacking it.
- codemac 5y agoGoogle does 1, 2, and 3 internally. If you join https://landing.google.com/advancedprotection/ https://landing.google.com/advancedprotection/ you can get something similar for personal public accounts.
- withinboredom 5y agoI prefer to keep my email as dumbly secured as possible. I’ll never forget this one time I was on my sailboat with no cell service and only an open WiFi connection from shore. I couldn’t login to anything via sms auth. Same thing with FIDO keys when traveling. Lost luggage? No logging in for you until you get home to get your backup? Cut your finger while cooking? No logging in for you! Have to wear a face mask? No logging in for you! To be clear, I don’t have a better solution. But all the second factor stuff is fundamentally broke when you are likely to need access to the service most.
- tialaramex 5y agoSo, I'm somebody who thinks about contingencies a lot and to my mind, there's just not a lot of gap between situations where you don't need credentials (e.g. satellite beacons don't care who you are) and where you don't have credentials (oh no, I lost all the gear) so it doesn't represent a big worry for me. I don't want the consular officials to be unable to authenticate me in a foreign country because I lost my phone, or for my bank to be unable to release funds because I don't have their card or my Security Key, but I feel 100% OK with losing access to Gmail or Hacker News, or whatever for say a few days until I can secure replacement credentials.
- philjohn 5y agoThe SMS point is part of why moving to FIDO keys is a good idea - the NFC enabled ones work with modern smartphones and allow you to login. As for lost luggage, I carry mine on my keychain, another one in the laptop itself (USB-C Yubikey) and one in my safe at home - if all three are ever destroyed or lost I also have backup codes available as password protected notes on several devices.
- staticassertion 5y ago
- mnd999 5y agoBleeding edge or complete fantasy? This is going to be very very expensive and guess who’s going to be paying for it?
- tssva 5y agoAs with most OMB memos it is complete fantasy and agencies won't comply by the date, any date close to it or really ever. The answer to the question "who's going to be paying for it?" is nobody which is why it will never actually get done.
- mnd999 5y agoGovernment contractors are expert at getting paid to deliver nothing.
- melony 5y agoIsn't 3 responsible for all those HN horror stories about being locked out of their Google accounts while traveling?
- warner25 5y ago"...fairly bleeding edge best practices..." By the time we implement any of these things, if ever, they certainly won't be. I work on military networks and applications, and it's hard for me to believe that I'll see any of this within my career at the pace we move. This is the land of web applications that only work with Internet Explorer, ActiveX, Siverlight, Flash, and Java Applets, plus servers running Linux 2.6 or Windows Server 2012. The idea of "Just-in-Time" access control where "a user is granted access to a resource only while she needs it, and that access is revoked when she is done" is terrifying when it takes weeks or months to get action on support tickets that I submit (where the action is simple, and I tee it up with a detailed description of whatever I need done).
- staticassertion 5y agoMaybe, but my hope is that this pushes external vendors that have government contracts to support these workflows.
- post_from_work 5y agoIt took us NINE MONTHS to get a server installed in a data center a few years back. This was Marine-Corps fielded hardware running an ATO'd[1] software stack for real-world situational awareness, going into a Marine Corps data center. The people that run the data center have a glacial Change Management process, exacerbated by everyone in their organization not talking to each other, even though they are separated by cubical walls. I too have no faith of seeing this stuff implemented anytime soon... [1] (Authority to Operate, basically approval from the highest IT authorities to utilize something on a DoD network)
- warner25 5y agoHaha, yes, my day-to-day work for the past two years has been fighting exactly this same fight on the Army side.
- Alex3917 5y agoGiven that every cybersecurity czar seems to publicly resign a few months after being appointed, what are the chances of these actually being implemented?
- raxxorrax 5y agoThese are strong requirements, but I fear the government just wants more transparency of citizens. Remote-attestation of trusted platforms could lead to the worst surveillance attempts we have ever seen. And it would require you to trust your government. That is a bad idea from a security point of view. edit: The source of my claim that governments tend to extend surveillance is pretty well documented I believe. So much so that I believe it is worthy to insert the problem into debates about anything relating to security. Because security often serves as the raison d'être for such ambitions.
- cabbagehead 5y ago
- cabbagehead 5y ago