This really rings true. Just think of all the nonsense you have to deal with in the name of "security." Mandatory password change intervals. Insane rules for constructing passwords. Completely undocumented password requirements that you just have to figure out by trial and error. Complicated error messages full of security jargon. "Secret Questions" that you can't remember the answers to. And on the other side of the coin, the security of these systems themselves is like a sieve. So many data breaches, information disclosures, they are in the news almost daily. I often wonder how they get away with it all.

Website: "Please choose a complex password of at least 8 characters including special characters and numbers"

Me: Fires up the password manager, generates a 128 character random password, feels smug.

Website on next visit: "Please enter the characters in the 31, 98, 102 position from your password"

Me: WTAF

Context: Mortgage website in the UK

Edit: It's now dawned on me that they're storing this plain text so that they can do this... or at least encrypting rather than hashing, meaning that they can always decrypt the password.

I didn’t know this when I made my account and fired up keepass per usual to create a massive random password. It takes me nearly 5 minutes of carefully pressing buttons on the screen and trying to keep my location in the password (you can’t see what you entered) just to get in.

One of my pals around that time turned on accessibility features like onscreen keyboards and diligently never typed a password. In a shell, a site, whatever.

It's unfortunate that these sites (Treasury and UK mortgage) were built around this time, but also shows that with all the progress with tech, security is still glacial in places. And like all tech, we get stuck with trends for a while (like skeumorphism in ux design).

A lot of GOOD malware don't "sniff keys" because that gives them random stream of garbage that has little value. No human is going to sit there and hand-decipher that garbage. Instead, they either inject browser extensions, intercept at the Win32 layer, or intercept the HTTP traffic upstream of the browser giving them the raw form-fields with URL which can be packaged and sold.

So all TreasuryDirect was doing, when they were doing this, was inconveniencing real people while the malware didn't even notice. Utterly insane. Glad someone had them quit it.

It could well be that they're doing the encrypt/decrypt thing, but you can also get the same affect by pre-calculating the slices of password and hashing those slices.

For example, when you create the new user entry, you could take the password, pick three random characters from it, and store the indexes and the hash together in a table row (in your case, something like ("31,98,102","salt$hashfgtd")).

You do that two or three times, and then, every time you ask the user to log in, you randomly choose one of these entries, ask the user to enter the character positions, and check the hash of the result against the hash in the row.

The Student Finance England website used to have a similar setup about asking for letters X, Y, and Z, but it rotated between only a handful of combinations, so I think it probably used something like this.

That said, a few years ago gov.uk took over the SFE login form and modernised it, including replacing the XYZ system with a version where you just enter the whole string, so presumably either they also had hashed the whole string, or they were storing it in a format that was retrievable. Or I guess they still only store the XYZ tuples but do the indexing and comparison logic internally.

I suppose an alternative approach would be to open a websocket in the post login page, and if you open the link in your email the server sends your browser a cookie or something, and then you're in. But I've never seen that approach.

First, it's not either-or. You can match against zxcvbn strength and some passwordlist.

Second, think of the output of zxcvbn as a very weak hash with a low collision rate. E.g. 'correct-battery-horse-staple' maps to an estimated 213811968952000000000 guesses. In addition to being potentially algorithmically reversible, attackers can simply perform an offline attack against the value 213811968952000000000. So, this metric should never be exposed (e.g. in log files, on screen, etc.)

Third, having the estimated entropy helps a lot when password cracking. If you have the password hash digest and the zxcvbn metrics, then it makes the cracker's job much easier by reducing the search space. (Think, going from checking each molecule of an apple to checking only each molecule on the peel of an apple.)

Further, it's not perfect. The zxcvbn library I used suggests 'correct-battery-horse-staple' is a very strong password!

This is Capital One by the way. My account was originally ING Direct, then Capital One 360, before being fully incorporated into the rest of their nonsense, and I assume that's related to the username situation.

My bank account (HDFC india) starts with 00. Dare send it to any accounting person who will copy paste it into an excel sheet and bang.. the prefix 00 is gone. Now they will complain that your account details are wrong. Took me a few months to figure out what was really going on.

Here in USA, Citizen's bank, iirc a subsidiary of Royal Bank Of Scotland, has had a bug for years that prevents me from changing my password. The only way to do it is via a series of tech support calls, despite the fact that they've had an open ticket for years. The source of the problem? Can't do it on an account where the email address (not the username) has a less-than-3-character-long name, as in "[email protected]". I own a small company and setup initials for easy-to-use email addresses, and found zero problems anywhere else in the world. But these clowns seem to need "abc@..." to function correctly.

I've found bankers tend to not be the brightest bulbs in the box, and this is but one example.

Edit: The issue was with the password field, not the username.

I've had business and personal accounts with SG, La Banque Postale, BoursoBank and CIC and they all worked with those 6-character "visual number pad" logins.

I think the others are just copycats. Someone must have come up with this first, and the others figured "yeah, that looks so secure, let's do that, too". If I had a penny for every CSO who justified some stupid "security" idea with "everybody does it, why shouldn't we?" I'd be so rich I wouldn't care about this crap anymore.

Obviously, if the computer reads aloud the password as you type it, it's an absolute win for security, and I'm sure some PMs somewhere are quite content with a job well done.

For the curious, here's the login page: https://mabanque.bnpparibas/fr/connexion

It's a bit of a 'Foreigner in China' stereotype to whine about how absurdly difficult it is to go to e.g. the bank or a hospital as a non-native because it happens so often.

Ex, i created the account with "mySuperAwesomeHunter2Password".

But the limit was somewhere in the middle so I had to enter "MySuperAweso" to log in.

They fixed it since then but I stopped using it except as a payment proxy. No money will ever be stored on paypal after that nonsense.

My favorite is:

1. I go to a website I haven’t used in a while but know I have an account on

2. I sign in with my email and what I’m sure is the right password for that site (algorithmically generated from site URL)

3. Password not valid

4. Ok, maybe this was an older version my my algorithm from way back

5. Password not valid

6. Fine, hit password reset

7. Get reset email and click it

8. Enter algorithmically generated password as new password

9. Error, can’t have that special character

10. Fine, per my rules, replace that special character with next one

11. Sorry, can’t reset password to your current password

12. Aaaaaargh.

I worked for the online investment banking arm of one of the big Canadian banks a few years ago. Their passwords could only be eight characters long. At one point, I was tasked to do some work on their IVR system and discovered that your phone password was entered by pressing the corresponding letter key on your phone keypad. But they didn't say "2 for A, 22 for B, etc." which really confused me. How did it know the passwords were correct?

And that's when I had a terrifying realization and tested it out on the website - they weren't magically converting your phone presses into ascii characters. No, they were converting your password into the corresponding numerics and saving that. Every single user password was a 6-8-digit number.

They upgraded their whole login system around the time I left that company, including implementing 2FA. Though their 2FA was SMS-based rather than using an known authenticator app system, so it still wasn't perfect.

It annoyed the hell out of me though when I was trying to put the required special character on the end of my too-long password after a required password change, and the only error message I got was that the special character was missing.

For umlauts, restricting the amount of support calls from people abroad where the keyboard doesn't have them.

For others, particularly when mainframes or other truly old legacy systems are involved, encoding issues somewhere along the transport chain.

It is really hard to listen to any security recommendation from anyone in the industry when there are SO MANY bad password rules that restrict what actual good long passwords are. Length restrictions, restrictions on special characters or UTF-8, password rotation rules. These examples of bank logins at major banks absolutely blow my mind.

https://xkcd.com/936/

and is site-specific with some leetcode subs or a magic number suffix is about the strongest password for login and for long-term user security and usability.

Maybe in another 15 years the security people at corporations will get their act together?

Maybe sometime we'll get legislation with some actual teeth on login security?

Password managers usually are either password-protected themselves or have biometrics, which suffice to deter random thieves. In fact, password managers are not going to show your password in the first place, they are going to silently fill in password prompts. The password cannot be clipboard-stolen, screen captured, or key logged. It is even more difficult to fish you (if the password manager doesn't detect the right program id/URL, it won't fill your password in -- unlike you).

If someone is looking over your shoulder with a supercamera he can get one password. If you are using a password manager, that's it. If you were using "an algorithm" to derive your passwords it is now possible he can now easily guess ALL your passwords. Most people aren't that good remembering good "algorithms" anyway. Maybe he needs to capture two passwords to do so?

Unless your algorithm is truly good, in which case you likely have to store it somewhere and that becomes your "password manager", which shares the same cons as a password manager itself. You are even at risk of your "algorithm" being guessed through a couple big password DB leaks, which are sadly ridiculous common, and this by itself puts you more at risk than worrying about supercameras.

I however don't have anything good to say re password managers that sync passwords over a centralized service, or worse, do so without proven E2EE.

(Not saying that simplifying several errors into one message is always bad. I think it's reasonable to just return a 500 without any info for everything that's caused by an unexpected exception on the backend.)

Most recent was setting a password for Rakuten Bank, saving it to my browser password manager, saving it to an offline password manager, and then two days later attempting to login and being told my password has too many characters. What.

This sounds like an erronious error, ie the error message displayed is not the correct error message. There was definitely an error but the error was not that you tried the same password as your current.

I hate erronious errors with a vengance, because they not only break user workflow but they break helpdesk work flow as well then it gets escellated to an engineer who quite often cant fix the actual erronious error but knows what the actual issue is and fixes that anyway.. meaning the erronious error never gets fixed and will mow hang around to chew up everyones time all over again.

such a silly way to waste so much time, over and over.

What exactly is this based on?

I know I've seen that listed as a requirement (well, actually can't be one of the last 3) on some systems that have annoying password requirements.

You want some indication that any leak of your current password actually hasn't been mitigated. A failure message that your password hasn't actually changed (due to being identical) is functionally the same as allowing the password change and giving a warning that the passwords were identical (modulo some back-end details like if the password salt has changed and if the password change date has been updated).

1) No words! 2) Can't reuse last 24 passwords 3) Excludes some special characters 4) 5 Security questions 5-10) Several other password requirements

Are the security questions case sensitive? Who knows.

^ "I understand that I’ll be required to certify that the information I provide to create an account is true and correct and that I’m the individual I claim to be. If I’m not the person I claim to be, I understand that I’m not authorized to proceed and that I should exit this form now. If I provide false or misleading information, I understand that I might be subject to a fine, prison time, or both."

Enter your password wrong and you're off to jail?

---

Your password must be 8 to 30 characters in length and must contain at least one uppercase letter, one lowercase letter, and one number.

Your password is case-sensitive.

You can’t use personal identifiers such as your first or last name, date of birth, or Social Security number in your password.

---

Here are some error codes the API returns:

  ["NULL_USERNAME", "NULL_EMAIL", "PWD_ILLEGAL_CHARACTERS", "PWD_CONTAINS_SPACE", "NULL_CHALLENGE_QAS"]

When she tried a variation of "Taylor Swift" it worked fine.

All because some 15 year old security document said that's what all their products adhere to.

Well, the good news is that everything you listed is known as a bad idea to both end users and people who understand security (which is, sadly, not most people who implement security policies).

Using 4 or more dictionary words provides excellent password security and you can do the same for all of your security answers too. There's a variety of free and paid for password managers that solve the issue of trying to remember all your secrets (great for backing up 2FA secrets too).

I'm not sure what you mean by "complicated error messages" but I assume it's errors that they expect the user to fix themselves, otherwise they could return a generic nonspecific error and a unique ID for you to provide when you contact support to get help. While it sucks to get jargon spammed, I feel like pretty standard human ineptitude at explaining an error rather than anything specific to security. I also think it's how many people feel about any error message that contains computer jargon (PC LOAD LETTER!?!?).

> I often wonder how they get away with it all.

My thinking (and experience...) is that most organizations are failing at a lot of things at any given time, even if the business overall is successful. Security is just one of those things. I wouldn't be surprised at a small elite organization not following that trend, but any sufficiently large organization is going to have incompetent people doing incompetent things.

> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).

It has much to say on all kinds of other password nonsense:

> Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well.

> Truncation of the secret SHALL NOT be performed.

> Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret.

> In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered.

I would not call 44-48 bits "excellent". It works if there's a good password hash being used, but if someone left PBKDF on basic settings then a GPU might be able to do 50 million guesses per second, or for a plain old salted hash 50 billion guesses per second.

The guesses per second, I looked up some hashcat benchmarks to get a rough range.

The only password rule that needs to exist is "use something you've never used before". That really does make it difficult for most users though.

If the company still pushes forward with bad choices its on them, but they should be clearly informed how and why those choices are bad.

Some caveats: 1. Nobody will be convinced to change the position on the first attempt, but seeds of knowledge can be planted in other peoples heads and some of those seeds will bear fruit later. 2. Being not nice, shuts down the passageway of ideas.

You COULD have a longer password, but the extra entropy is probably excessive. It probably increases the chance of password reuse problems, so pragmatically it may be worse.

I wouldn't recommend this approach in general, however.

companies hire data science to ascertain human behavior, but this is not understanding the customer. if you want to improve your products and actually understand the customer then start giving your customer service or customer experience departments a financial boost instead of treating them like the bottom feeders of the entire company.

> I often wonder how they get away with it all.

unregulated industry + no union. tech workers practically beg to be exploited.

I'd replace "engineers" with "product owners". I'm sure the engineers at Microsoft know some of the stuff they're doing is braindead and are unable to do anything about it.

- In MS Authenticator, having to click on each subject rather than just showing the code immediately. If Google's Authenticator can show the code, why can't MS's?

- Azure DevOps randomly redirecting to the login form and back while already logged in.

- Azure DevOps randomly opening an authentication popup (presumably some SSO stuff) and closing it again

- Clunky-looking Office365 account management flows

If you have multiple accounts open in the same browser session, regular Azure portal won't remember which one you chose when opening in a new tab. If you got to a new tab by clicking a link, it will send you to select which account you want, then helpfully send you to the portal homepage, forgetting the initial URL.

Well, that was before. Since a few days, they seem to have improved the experience, since they no longer ask which account I want to use, but helpfully pick the first on the list. No, they still don't remember which account was already being used when clicking the link. And no, switching accounts from the top-right icon doesn't keep you on your current page but sends you back to the portal homepage.

Then there are other webapps which seem to implement their own login flow: they figure your session is expired, but don't allow you to switch accounts. The only way to use a different account from this flow is to sign out of the current one, which, of course, signs you out from everywhere. The solution is going to a different site, say myaccount, login with the second one, go back to the first site which now allows you to choose.

The worst one involved hitting cancel 8 times in a certain window, which you let you in. Lol

#YesterdayILearned the highly-appropriate phrase "breach fatigue."

Years ago, I went through this process with Blizzard:

1. Blizzard started deactivating my World of Warcraft account on the grounds that I hadn't paid my subscription.

2. I would log in and pay for a subscription, reenabling the account.

3. (Steps 1-2 repeated several times. Blizzard never provided any explanation beyond the fact that, in their opinion, my payment was invalid, which it wasn't.)

4. After several rounds, Blizzard disabled the account completely, requiring me to contact customer support.

5. Customer support, for the first time, informed me that the reason my payment was viewed as invalid was that the preferred payment card on my account was set to a different card. The card I was actually using was also listed on my account, but it wasn't the preferred card, which made it invalid.

6. Since my account was disabled, I didn't have the option of paying with my preferred card. I had to answer my secret question.

7. Since I am not stupid, my secret question didn't have an answer. It was a long string of random characters which I didn't know. But customer service happily accepted my oral answer of "it's gibberish", defeating the purpose of the secret question.

So I guess the lesson here is that the correct way to answer a secret question is that you need to provide an answer which...

(1) Looks like a real answer when customer service looks at it, so that they have a better chance of rejecting someone who doesn't know the answer; but also

(2) Doesn't belong to the class of answers that would be easy for someone to guess, such as a car model when they ask you for the model of your first car.

These requirements are incompatible with each other. I don't know what secret questions are supposed to be doing. And I have to note that my assumption that there was no reason for anyone, including myself, to know the answer to my secret question would have been completely correct if Blizzard hadn't made the decision that using a payment card that was already registered to my Blizzard account was a sign of fraud.

So I guess in the end their recovery process was susceptible to some good old-fashioned social engineering.

I thought up this schema after the last and only time I needed to use a secret question over the phone, when I read 32 ASCII characters to an Apple employee (which didn't work, but then they enabled a skip button for me to use).

Even my simple requests like not auto flagging emails from confirmed and fully validated Microsoft services gets denied because it’s “too hard” so everything except internal users and random whitelisted services like github and azure AWS is instead flagged as suspicious, causing alertness fatigue.

I’ve reported major logic problems to many major companies and usually the only response I get is an indirect followup email through HR or some other non technical people sent to the entire distribution list as a followup saying how it’s technically better than what was there before (it’s scientifically and mathematically not) and that we just need to do it.

I never get recognized or win bug bounties because there’s always some loophole where I didn’t actually help them and they just magically fixed the long standing issue by coincidence after I reported it.

Most recently, I discovered a “feature” with Microsoft OAuth that has a severe flaw and could essentially shut down all MS OAuth functionality, and all consequences branching from that. Still no response.

I’m not even trying to find these. They just keep getting in my way of trying to do work.

For example, I have to authenticate up to FIVE times per authentication, per authentication —- Auth syncing can be slow leading to multiple auth requests that would otherwise only need a single one to propegate.

5 authentications * 5 programs needing individual (slow-sync) auth = 25 authentications I have to already pass to be able to start standup or pass in order to un-hard-freeze my live demo to potentially hundreds of engineers.

Imagine driving your car, and the steering wheel locks when it loses internet connection (like in a tunnel or just randomly) or because the re-auth period has passed. Security devs don’t want to full stop the car because they’ll get yelled at, so just lock steering so they can’t steer home.

Well now if you’re on a highway, that’s pretty stressful and dangerous. But it’s like they are just salting the wound by adding a series of glitchy minigames where you have to first read all the spammy popup dialogs, and then solve a Baldi’s Basics math puzzle, and then rotate a ball to not be upside down (?) and then manually match a missile launch code.

That... That is literally what these "security practices" force you to use. You literally used an example of the ubiquitous "at least one uppercase letter, one special character, and one digit" requirement

This entire thread is about places that clearly have no clue about best practices.

> I haven't come across this.

You sweet summer child...

Don’t defend these idiotic practices.

and then the deeper question is, why do i need to create an account for this?

Is no-one at Microsoft actually using their own Authenticator? Unless I'm missing something, this would make it nearly unusable for almost all applications - as soon as you've used your email for one site you wouldn't be able to add it for any others?

Yet there's a search bar in the iOS version. Just why?

I'm willing to bet that in that gigantic Piper repo, there's already a local search library that they could just drop in in a single CL. But that's not LLM.

When I launched GA all of my 2FA data was gone.

Thankfully I had my backup codes. And I could also still use the old one on the old phone. But the nightmare potential is quite high.

(My passwords are copy pasted from somewhere else, so admittedly not 2 different factors, but at least 2 independent ones.)

So in short, even though I probably use 1% of the 1P functionality, I can recommend 1P for replacing GA.

They now have cloud sync, which I don't really think is a good idea. But it solves your problem of migrating devices. However I've already moved on to Aegis, because I'm done fling scrolling through my Mahabharata of TOTPs to find the correct account.

This is widely known and IMO a very good argument to use a different TOTP/2FA app than Google Authenticator. There's plenty out.

Personally I use Bitwarden pro, which lets you add TOTP keys directly to the account you're using it for, integrating it into the login-process. Very smooth.

And it sync/backs up across all my devices.

Something I have: the database file.

Something I know: the master password to that file.

I figure the sprit of the advice is preserved for the most part. (Doesn’t keep me awake at night, anyway.)

Entering multi factor hell just to get into Teams is something I’d happily pay to avoid.

These seem to be relatively current instructions: https://learn.microsoft.com/en-us/entra/identity/authenticat...

Having found a friendly sysadmin to do this, ask them to specifically not "Enforce key restrictions" which is theory could let your empoloyer require employees to use a specific issued authenticator credential - are they going to buy every employee an authenticator from a named brand? No? Then this must not be switched on, easy.

Once this feature is enabled for you (you may be able to get them to switch it on for the whole org, or maybe for IT or whatever department you work in) you should be able to enrol a new Security Key the same way you'd add other MFA.

So why go to all this bother? Because you can buy a Security Key that works how you want, a physical piece of hardware you own and can re-use - if you buy say the Yubico Security Key 2 in USB A, that goes in your USB A port on the laptop or dock and it just stays there. Its job is to be "Something you have" and the "Something you know" will be a PIN of your choosing (it literally doesn't leave your device, so corporate can't decide it should be the Password Game on steroids)

No need for a phone or other unrelated device, no opening fiddly apps, no transcribing codes, you type your PIN and touch the sensor. If a PIN is too much, some pricier options take fingerprints, so then you just touch the sensor (with the correct finger)

If it's always there, then why isn't it just a file on the disk? Why should I need to buy a new piece of hardware and permanently sacrifice one of my USB ports. Client certs have been the "something you own" for decades and the main problem with them was that using them didn't involve any JavaScript, which is blasphemy in modern web dev and so they were killed (with the help of EU bureaucrats). And now that basically every computer has a TPM, you can even satisfy the "not extractable" requirement, which was the only actual advantage of a yubikey.

Only almost all and increasing number of their revenue producing product depends on this being reliable, or at least have no bad reputation being unreliable. As the reputation is what many corporate ballonheads only care about. Still, hurt that too in their incompetent bencounter singlemindedness.

At most, I'd expect people to only use it for work, where Microsoft is the only issuer.

I also expect lots and lots of people to not use it.

Yeah, something is not making sense here. I've got multiple accounts with the same email and just compared the codes from Authenticator, which is my backup TOTP app, with the correct codes and Authenticator agreed.

I did find a UI problem that could lead to a user getting the wrong code. When the first few accounts are on the screen and it is time to refresh the codes the ones on screen refresh every 30 seconds.

The ones offscreen do not. When I scroll to bring offscreen codes into view they show an older code. In one case the code that scrolled in was 4 codes behind the correct code.

I used to use Google Authenticator with my GMail accounts, but disabled that out of fears it's just one more thing to go wrong, with Google providing little recourse.

My password is a bit over 96 bits of entropy, generated by extracting 256 bits from /dev/urandom as a multi-precision integer, divmod'ing to extract one instance from each of the character classes (digit, lower, uppper, symbol) and then the rest from the combined alphabet (digit + lower + upper + symbol), and finally the leftover entropy used for Fisher-Yates shuffle of the password so the first digit isn't always a digit, etc. Passwords are per-site, stored using a gpg-based password manager I wrote in the early 2000s.

MFA would still help for some types of ongoing active compromise, but not for dumps of password hashes from a DB compromise. It really kills me that recovery from my recovery email address doesn't work, even though I know my password.

Honestly, if you haven't logged in from anywhere in a few months and you have the correct password, they should at least just send some verification link/code to your recovery address without requiring you to tell them your recovery address. Sure, maybe don't say where you're sending the recovery link, but turning the recovery address into another password you need to memorize without ever telling you it's some weird combination of recovery email address and recovery password is just highly annoying.

I set recovery address to an other (dormant) gmail account, just to aggravate the risk put upon me! :D (I do not trust google now with more data than I already given and must give, see later)

I need to speed up the migration of my email life to the paid account I initiated and testing (protonmail) because some serious problem could emerge otherwise (there is an international move on the horizon). I started to give gmail to various governmental (taxation, healthcare, authorities) organizations when it was innocent, as contact of the account used for light things at the time, when everyone started to discover how to manage bureaucracy online. Which succeeded and my gmail became an important tool managing matters throughout some international moves. Some accounts here and there are dormant but still with important matters that I might need once (how is it with that many years valid Australian travel authorisation or what that I did not need last year?...). Still gmail was innocent enough, despite the mass surveillance sped up, which was a bit inconvenient feeling but rarely got any real secrets or deeply persoanl matters apart from the fact I have dealings with that organization here and there. But now, as online administration is borderline mandatory being other means left to the bare minimum (when I am sent online in an office for something, that's a turning point in mind) or in other country. Gmail is very inconveniently in the center with all the worrysome things their automated bots carry out against unsuspecting user without mercy and appeal, that the migration process had to be started. Hence test with protonmail. But it so damn widespread now, I have not enough time going through all, some forgotten and need to dig into faint memories, it is torture. But has to be done. Has to be done.

Our twin girls should not be put up with the mercy of google bots when they get into the age of requiring email for official matters.

I think I was talking to a bot and they made it appear human by slowing everything down so the whole exchange took 30 minutes, but maybe it was just a human following a script. Either way, it was worse than if they didn't have support since they just wasted my time.

I’ve started a project to attempt to move to my own domain and self hosting full email stack. It’s a huge amount of work. However the power Google has over me, should my gmail account be hijacked or turned off is incredible.

Starting from the bottom is the security of the domain registrar and DNS records. It looks like there are some good options, though obviously with additional price. Basically you have to use the corporate services with additional security features.

The self-hosting email and server security is something I have the background to handle.

> Action required: Enable multifactor authentication for your tenant by 15 October 2024

> You’re receiving this email because you’re a global administrator for [Literally a UUID here, no organization name or anything] Starting 15 October 2024, we will require users to use multifactor authentication (MFA) to sign into the Azure portal, Microsoft Entra admin center, and Intune admin center. To ensure your users maintain access, you’ll need to enable MFA by 15 October 2024.

> If you can’t enable MFA for your users by that date, you’ll need to apply to postpone the enforcement date. If you don’t, your users will be required to set up MFA.

> Action required

> To identify which users are signing into Azure with and without MFA, refer to our documentation. > To ensure your users can access the Azure portal, Microsoft Entra admin center, and Intune admin center, enable MFA for your users by 15 October 2024. > If you can’t enable MFA by 15 October 2024, apply to postpone the enforcement date.

The thing is, I'm not administrating any organization with Microsoft.

I have a private office365 family account or whatever it's called, and I have 2FA set up for my account, I have no idea what they are on about, especially because the email doesn't contain even my name or the name of the supposed organization, just some ID.

It's definitely an Email from Microsoft though.

https://bugs.webkit.org/show_bug.cgi?id=270553

Safari still has some bugs where it can't discern between websites hosted on different Subdomains except for hardcoded exceptions and it will override password of one subdomain with the other. Happens to me on a monthly basis.

I've never gotten that dialog, and have not had any issues with the accounts I've added. Since they're my work accounts, 99% of them share my work email as account name.

So does that mean I've just been lucky, in that the sites I've signed with have provided a sufficiently unique label? I feel I didn't fully get what the issue is.

The whole online identification is seriously unreliable and full of big wholes, and much bigger risks, yet we build our whole life on top of it. Still using passwords after decades (Yes. Decades!) of serious harm caused by insecurities with it, and trying to patch with plasters or just some paint?! We are so damn stupid, almost no week goes by without some online system gives away serious bits or complete set of personal details of the masses easy to abuse and we just sit in the middle of the burning room like the coffee sipping doggy with that stupid hat and smile in the meme 'this is fine, this is fine'. Lets choose some longer than 8 character password, different for all system just to be safe, we are going to be fine, we are going to be fine.

Even though it might be a dumb feature as seen from the users POV, it seems sufficiently special that it's something that I would assume one would want to have feature parity on.

Spot on right. They should have been more prudent in selecting services. Absolutely right, users' and clients' fault it is!

You see a smug bastard company that hurts the client they live on because they provide faulty service, they hurt repeatedly, in thick queue throughout time, for long time, fault after fault after fault and just release the smear the responsibility elsewhere department on the clients complaining, whatever the official title of this department is, PR or whatever, while the issues are reported in news everywhere, publicised, then who would you blame? The company, or the clients still choosing the company against common sense and own experience?

The case touches me because I am approaching a job where I would not use Windows anymore, I am tired of the Windows ecosystem. It only makes life differently complicated, or many times more complicated, more difficult to do my job than without it. I have not enough time listing how many things they made much worse in the past decade or more that my every day is a swimm through the flow of piss MS releases day after day at all of us. They were better in some short period long ago, only partially still, after some very bad historic period, now they are determined that with hard work they will f up all what is left.

I have a friend working on the MS Teams. He is very busy, working hard, they will release some sort of AR meet feature, packed with complex and revolutionary (i.e. experimental) approaches so you could enjoy solutions that probably will work ok and not annoy you with visual artefacts and problems not eliminated before release, with the headset you require for it, probably will not be forced on you but likely annoy the hell out of you by the pop up promotions when you try to do your urgent job after a critical update. Who the f needs that? While the Teams is a mess to work with already with lots of noise and half cooked bloated whatevers already being a distaction, not helpful, not at all. Probably only the call quality is the only good in it by now, but that was purchased from elsewhere, that was given to them. They are so good making things too complicated and being unable making it well because it is too complicated to do well, too expensive, so let's just release a half cooked one and leave it there for decades (like the dialogs in Windows) and put the blame on elsewhere by the put the blame on elsewhere department put together precisely for this.

I even have a matching icon of the issuer for each entry; the issuer is registered for each entry.

I am using the MS Authenticator for years and I've never had any problem of that sort, and of course, I am always using the same email as my account/username.

Anyway, I'm just putting the result of my test. It's not like this going to change your mind about the authenticator or Microsoft itself here...

Sorry to hear that!

I've been burned too many times.

This seems to be my normal experience with a new phone for MFA apps. I’m doing something wrong. That and setting up email are so dreaded that I hold off updating.

If it's a MFA I actually don't care much about (security-wise), I simply save the token on bitwarden so it autocompletes for me (it defeats most of the main point of "multi" FA but I don't care about it to begin with).

Printing is not a bad idea, especially for backup, if you put them in a fire-proof safe or something. Make sure to give each a name to know which service they are for.

Do they do it because they can? Haven't used Android in a long time, but I had the impression that they also introduced finer-grained permissions, as opposed to blanket approve / deny everything the app asks for.

I don't recall a prompt for Apple's services, either. But you can revoke the permission, at least for some of them.

Depending on your threat model this may be an issue.

I am sure whatever is going on, it’s a bug and not a feature.

Today it's a MS fuckup, but any such system could malfunction.

Generally, unless you are targeted by someone with a sim swap, it is good enough. Most people won't be targeted, but do have a good chance of something going wrong that makes them lose their MFA key.

For personal use, that equation is wildly different. Google isn't going to let you attach a brand new key, you've just lost your account forever because it rained.

Trying to imagine your grandmother setting it up herself to be able to log in to her Facebook is another matter, and why these things have never worked for the general public.

At home Yubikey is probably synonymous to FIDO not PIV/PKI. No whipping up a new one if you lose it. You better have 3 of them enrolled at any time, and have at least one stored off site.

I agree it requires significantly more work when you can't just call the locksmith for a new one -- IT -- if you lose one on your personal account you can only go get the spare key hidden under the doormat, a printed code in your safe, or lose the account.

Most services won't even need a second layer of auth, if someone steals your wallet - do they really care about your reddit account?