Yeah, you’re right. Passkeys, sso and password managers make it impossible to get any work done. It’s much better to keep doing the same things that haven’t been working for decades. Don’t forget to make everyone rotate their password every month!

What’s your simple due diligence to prevent phishing? You check the links you click, verify the URL you ended up at is what you expect, validate no unexpected unicode swaps in the domain, pop back to the email and check the sender is known and trusted, look at the headers and validate the routing chain, then double check the sender spf and dkim records are on the up and up? Oh, and make sure the actual content that you landed on is from the website and not a hijacked subdomain.

they have no reason not to trust them as a coworker doing their assigned job

That’s the specific area where they don’t. We’re discussing a specific situation where the security team is taking it upon themselves as their job duty to trick you and get you in trouble. That makes people hesitate to share security concerns because “those guys are pricks and will make this all my fault”.

Losing your job because ransomware

It’s a hospital. They’re already short on nurses and administration staff. Those people directly provide patient care or manage operations. Security does not. Securities job is to maintain security standards compliance and maybe keep patient data safe. It is not to exacerbate a staffing issue or let the network go down because you thought it was too much hassle to do your job and properly secure a fucking managed laptop. Security is, rightly, going to be blamed when a user gets the network infected. Particularly when your idea of training is to offer them PTO and then call them an idiot when they want it.
The person making the decision on who to blame is a lot more like that poor nurse than they are like security.

Sure, but that’s ignoring the cost of “now your users don’t trust the security team”.

For most things like phishing there’s only so much training you can put on a user. Humans are pretty okay at understanding the costs associated with their time in an implicit manner. Users will check well enough to meet their internal cost metric: the cost to them if they get phished isn’t high, and the likelihood is low. That’s why it’s such a problem in workplaces.
The solution isn’t to keep beating the user over the head. First, it can undermine other important parts of the relationship between users and security as I mentioned, and it can , if done in the extreme, normalize phishing emails. The real Phish comes in and sits unreported next to the fake ones. Security never gets to run a scan and remove the message from every mailbox, increasing the exposure.

The better approach is to prevent users from being in control of their own vulnerability. Don’t let them enter their credentials into the nono box.

My entire point is that none of that is actually new information. Every piece of research by anyone has always indicated that the human element is the weakest part of the security system. If you’re asking if you can trust a user to reliably do something, you can safely say “no” and make contingencies for when they don’t.
If they have technical solutions available, they didn’t need to run a drill to know that they should use them.

It’s not about being “liked”. It’s about effectively enforcing a security posture. An adversarial relationship does more to undermine that then providing guidance on how to do it better.
They have no obligation at all to “run scenarios” where they could just implement the fix to the problem.

They exposed a fatal vulnerability in the same way stabbing someone exposed a problem: it’s been demonstrated, but it’s not new information.
This type of excercise is about producing numbers that look good on a spreadsheet. You do a phishing drill, people fail and then you run a training. A few weeks later you do it again and since people still have the previous drill lingering they remember, and you send a softball phish. Line go up and to the right. Looks good in report.

That’s not new information though. All they’ve done is teach users that their security team is more of an enemy than a friend.

Seriously: what action are they going to take as a result of this that they shouldn’t have already been doing? They could just as easily have assumed, entirely correctly, that users will fall for phishing messages. Don’t need an excercise, to say nothing of a mean one, to learn that.

Sure, but here’s the critical thing: the security team isn’t a threat actor, they’re coworkers. Their job isn’t to steal data but to protect it and get coworkers to better protect it.
Doing stuff like this doesn’t advance that goal, and actually hinders it. Now a bunch of people think the security team is full of assholes and the lesson taught is “the security team will trick you, get you in trouble and also good things never happen here”.

They now know that they could face a breach from an enticing phishing email, which isn’t actionable. What do you do with that information that you shouldn’t have already been doing?
The cost is that now when someone does something like actually fall for a phishing attempt they have less reason to trust that security is on their side, and more reason to brush it off and try to obscure it to avoid getting in trouble with security.

A better way to train users is to use rewards. Tell them you’re running a phishing campaign and properly reporting it gets a chance at a gift card or prize. Then tell them you’re going to keep doing it, and that legitimate phishing reports also get a chance.
It costs you $100 a month, no one is mad at security and it’s easier for users to see it’s an excercise rather than an attack.

That actually makes security much, much worse. It’s training users to make authenticating part of their continuous routine, so when a random site that looks like the login page asks for their password you’re inclined to simply proceed, since diligence has an excessively big time cost.
Same goes for mfa. If validating every request, particularly if you use a service with push based mfa, takes too much effort then people just fulfill the request.

The ideal is that you only authenticate when it’s actually important, as an exceptional circumstance that makes the user pause and make sure things are good. Changing the bank account your pay gets sent to warrants an authentication.
“You’ve been using email for 20 minutes” doesn’t.

Realistically your session should probably be about the length of a workday with a little buffer for people who work a little longer to not end up with 99% of a session sitting open on their laptop. 9-10 hours should be fine.

You want the machine credentials that a laptop uses to talk to the mail server, or the hr software uses to talk to the doobips to have short credentials so if someone hacks the mail server they have a short window to use them, but that doesn’t impact user authentication requirements.

It can totally be fine for your needs, and secure while it does so, and not be two factors.

It’s a question of what’s required for access. In this case, they would need your password and to have had some manner of device access at some point to steal the value used by 1password to verify you at one point had the secret key. Someone with a keylogger from a random untargeted malware infection could plausibly get sufficient information. It’s really good 1 factor.

To be two factor there would need to be a requirement for two factors to be demonstrated at auth time. For example, if 1password encrypted the passkeys in such a way that the passkey could not ever leave the device, like via certain types of hardware backed key storage, then unlocking the vault is proof of something you know, and the usage of the signature is proof you have the chip.
The trickery comes about in the techniques available to move the passkey between encrypted hardware devices without it ever being exposed or loosing the “device you control” assurances.

For the record, I use 1password. Just not for passkeys on desktop. I prefer the Bluetooth connection to my phone, since phones currently do a much better job providing uniform targets for what’s needed to provide the proper two factor for something like passkeys.

There are secure ways to transfer the key that preserve the properties that make it useful as two factors in one.

Basically, the device will only release the key in an encrypted fashion readable by another device able to make the same guarantees, after the user has used that device to authenticate to the first device using the key being transferred.
A backup works the same way.

You can do that without an extension. There’s a bunch of different protocols that let you, for example, use your phone as the authenticator.
You can log in with your phone on a computer you’ve never used before by scanning a QR code and credentials never leave your device.

My passkeys are tied to my phone, which I use via the browser and OS. I keep them in my password manager running on the phone. My password manager supports the open spec for securely migrating credentials between vendors.

It may be difficult to believe but they want you to use them because they’re legitimately significantly better.

Users are silly. They blame Microsoft for bad passwords. They blame Google for forgotten passwords. They blame Facebook when they click on a phishing link. They blame apple when apple “lets” someone who they gave their password to see their pictures. They blame apple when they don’t let the user in just because they forgot their password and every recovery mechanism.

Everyone involved has a significant issue with passwords because they cost them user satisfaction, credibility, or money directly. The reason cross vendor transfer has been slow is because everyone wants to be the leader, since if everyone follows your lead you get to make it work better with your stuff.

That ones because users like choice. They need to look up who you are to know how you’ve chosen to authenticate. At least, that’s how it started. Some could be doing it because the big kids are, but that’s why the big kids do.
And they support choice because businesses want to use their login infrastructure and refuse to share. So you enter “user@businessOrUniversity.com.edu” and it forwards you to your institutional login.

They inevitably didn’t write it for that reason. They wrote it to say the field is invalid until the user changes it to be valid after someone landed on the page holding the enter key down and instantly locked themselves out after submitting the form 50 times in 3 seconds.
Unless you know otherwise, it’s easy to think that “form interaction” is the same as “form changed”, and one of those is much easier to check.

I’m unsure what you mean about passkeys. I don’t think I’ve heard anyone mention significant concessions to os makers and I’m pretty tuned in on the topic.

Depends on the system. The thing where your password manager is managing your passkeys? That’s a single factor unless it’s doing something tricky that none of them do.
When it’s the tpm or a Bluetooth connection to your phone? That’s actually two factors, and great.

That’s not what that research document says. Pretty early on it talks about rote mechanical processes with no human input. By the logic they employ there’s no difference between LLM code and a photographer using Photoshop.

Yup. The risk of someone breaking into your house and stealing your post-it note is vastly different from someone guessing your password, and the risk changes again when it’s a post-it note on your work computer monitor.

One of the best things you can do with your critical passwords is put them on a piece of paper with no other identifying information and then put that piece of paper in your wallet. Adults in modern society are usually quite good at keeping track of and securing little sheets of paper.

I’m paranoid, so I put mine on an encrypted NFC card that I printed to look like an expired gift card to a store that went out of business. It’s got what I need to bootstrap the recovery process if I loose all my MFA tokens (I keep another copy in a small waterproof box with things like my car title. It’s labeled “important documents: do not lose” and kept unlocked so any would be thief feels inclined to open it and see it’s worthless to them rather than taking the box to figure that out somewhere else. The home copy is important because there’s vaguely plausible scenarios where I lose both my phone and wallet at the same time. )

Stealing my laptop and getting my stuff is a significantly larger risk than me leaving my computer on and unattended without locking the screen.

Passkeys are a good trend because they’re just about the only security enhancement in recent memory that increases security and usability at the same time.

My standard for an orm is that if it’s doing something wrong or I need to do something special that it’s trivial to move it aside and either use plain SQL or it’s SQL generator myself.

In production code, plain SQL strings are a concern for me since they’re subject to the whole array of human errors and vulnerabilities.

Something like stmt = select(users).where(users.c.name == 'somename') is basically as flexible as the string, but it’s not going to forget a quote or neglect to use SQL escaping or parametrize the query.

And sometimes you just need it to get out of the way because your query is reaaaaaal weird, although at that point a view you wrap with the orm might be better.

If you’ve done things right though, most of the time you’ll be doing simple primary key lookups and joins with a few filters at most.

They likely did do actual training, but starting with a general pre-trained model and specializing tends to yield higher quality results faster. It’s so excessively obsequious because they told it to be profoundly and sincerely apologetic if it makes an error, and people don’t actually share the text of real apologies online in a way that’s generic, so it can only copy the tone of form letters and corporate memos.

You’re currently connected to your neighbors that intimately. Chances are a good chunk of your neighbors are on the same ISP as you.
What disconnect do you think a non-local ISP is providing that a local one wouldn’t?

And they clarify that you can choose to have them not do that.

They don’t. They’re saying they don’t have it.