USDS may only get away with this because their roles are term-limited excepted service, but pretty much everyone comes in as a GS-15-10, regardless of education.
It'd be unreasonable to ask someone to perform a hash of those last four digits (how would your mom respond if the bank asked her for the sha256 hash of her card number?), but it could be helpful to ask questions that don't reveal too much information, like, "is the sum of the last four digits even?" or "is the sum evenly divisible by 3?"
It would be difficult to come up with something you could reasonably ask an account holder to figure out on their own that also wasn't easy to randomly guess.
> Do thirtysomething's still use Facebook ironically, or something?
Not among my peers. Facebook is seen as a way to communicate with older and tech-challenged relatives. It's in the same category as LinkedIn -- a social network whose content is mostly cringe and that you're only on as a means to an end, not because it's a good product.
Oof. I wonder if admins can disable push notifications and just fall back to TOTP instead? Though it does sound like that would not be convenient if you have to enter a TOTP every time an RDP connection get interrupted.
Don't you have to provide some information as part of the confirmation? Whenever something requests MFA, it will show a two digit number, and in the Authenticator app, I will be presented with three numbers and can only confirm the prompt if I select the same number that was shown by the requestor. My work MSFT account is even more locked down and requires me to type in the number.
I would say yes, Azure AD is more complex, but in a good way.
AWS IAM is interesting in that IAM resources are provisioned within a subscription. You can use IAM as an identity solution, giving everyone a user account and password, but you don't have to. Internally at AWS, we never used IAM users, but instead had an enterprise AD deployment that we used to log in to our computers and internal systems. One of those internal systems kept a list of AWS subscriptions and IAM roles you had access to, and would trade your AD credentials for temporary AWS credentials scoped to a role. It was pretty slick, but it's not inherent to IAM, so you typically need a third party service to do this for you. (At the job I had in between AWS and Microsoft, we used CloudTamer, and before that, we just had to keep track of 20 different username/password pairs.)
AAD on the other hand is a full blown identity platform that incidentally can also be used to log in to Azure. That means it integrates nicely with on-prem AD deployments and, more importantly, lets users log in once and navigate the subscriptions to which their account has been granted access. So it's actually simpler to use if you just need to be able to log in to multiple subscriptions, but you can run into cases where you need to operate on AAD resources in ways that aren't supported through Azure APIs. This primarily comes up if you need to grant a non-Azure permission as part of an Azure deployment. E.g., if you want to give a managed identity permission to read AAD metadata like service principal IDs, you can't do it from within ARM.
Rasmus borrowed this distinction from Larry Wall, since PHP was originally implemented in Perl (which also uses + for addition and . for string concatenation).
I'd echo others and say this boils down to familiarity more than anything else.
Identity and authentication is honestly the one area where the popular cloud platforms differ the most. I used to work for AWS and currently work for Azure, and the switch from IAM to AAD caused more cognitive dissonance than any other difference between the platforms' respective offerings.
I've seen a lot of projects that use a full response cache to capture a view with holes where user-specific information would go and then fill in those holes with some client side JS. I wouldn't call those SPAs, though.
But I'd say it's more common to just use "private" cache headers in this case for any page that differs for logged in vs unauthenticated users. The user's browser will still serve as a full page cache, but shared caches will ignore those pages.
> I preload basically all the data a user might need at startup
This can be a great strategy when you're dealing with bounded data that's not sensitive, but it's important to recognize that this approach is often inappropriate. A web app may be allowing users to wander around terabytes of data, or it may need to make highly consistent authorization determinations before allowing a user to see specific data, or you may need to keep a highly detailed audit log of who requested what when (e.g., if the app targets healthcare or government users), which aggressive preloading would render useless.
> The distinct advantage of an SPA is that, done correctly, cached data lets you render pages instantly.
Yeah, but full page caching is a thing, and in my experience, teams writing traditional server-rendered pages are much more aggressive in their use of response caching than are teams writing JSON APIs. Honestly, a Rails/Django/Laravel app with smart caching headers and a Varnish instance in front feels more reliably instantaneous than the bespoke caching solutions each SPA seems to invent for itself.
The GP was not saying "bad software is bad"; they pointed out a lot of footguns that are introduced by going the SPA route. "More code -> more (opportunities for) bugs" is the truism at play here.
The Bahamanian dollar has a fixed exchange rate of 1 USD, and I believe this has been the case since 1973. The economic mechanism that allows this to persist is also the one that keeps gift certificates denominated in USD pegged to the USD.
I realize it's not hip, but I use OneNote. I used to keep notes + a work diary in markdown in a git repo, but it was difficult to integrate screenshots, and converting a note to a task was always a manual process of copying text into a separate system. OneNote's native integration with Outlook tasks was the killer feature for me.