Who are you again? Infosec experiencing 'Identity crisis' amid rising login attacks Infosec pros are losing confidence in their identity providers' ability to keep attackers out, with Cisco-owned Duo warning that the industry is facing what it calls "an identity crisis." Only a third (33 percent) of the 650 cybersecurity leaders in North America and Europe said they were unconcerned about the security their …
"You don't have to buy or carry anything else around, and if you lose one, just use another to register the replacement."
Do I really need to link everything to that single device which is eminently stealable? Ah, you think we all have multiple devices. OK. Do your solutions work reliably under all platforms? Like... BSD or Linux? How many devices do you think I have? OK, I have a bunch of old phones kicking around - none still work, because the battery is shot. So, not those. No, I don't own a working tablet (batteries shot due to not using them). And for many people, the smart phone is the only device they use, so they are pretty much screwed.
Yes, but one you don’t have to remember, so it has enough entropy, and that you’re not using all the time and putting at risk of keylogging etc.
So actually, no, not really.
Strangely some of the best security minds on the planet have spent time thinking about this (I am not one of them, I would hasten to add, but have spent a little while working this through).
You fall back to physical security on the backup code, if you use one. For most people that’s not a bad tradeoff between availability and confidentiality. If the person attacking your online accounts can also extract the backup code from the hiding place in your house, you’re likely pretty much screwed anyway.
The important point is that you’re not using this code every time you login, so you can afford to hide it well. So it’s still not like a password.
Alternatively you could use a second device with a stored passkey in a secure element with biometric protection for recovery, aka another phone in the hideyhole, but the author of the thread didn’t want one.
This post has been deleted by its author
The 'best security minds on the planet' don't live the lives we do. So they can piss off and let us carry on using long, unique passwords for services or, at worst, clunky old 2FA, without giving big tech another way to restrict/control/end access to services. Biometrics and passkeys are a toxic road. Do not use them. Walk away from services that do.
Restricting access to services is what authentication is *about*. I don't see how passkeys add any more opportunities for control - why do you think they're toxic? The biometric and the private keys are only ever on your local device. You never distribute anything sensitive to the third party, it's a true open standard - they're much better in my view.
Passwords are toxic to me - a relic of security thinking from half a century ago when the world was very different. They're either short and insecure or long and unmemorable/untypable. You're dependent on the service storing and using them sensibly, and there are many ways for them to do it wrong - it's done more wrong than right. Password managers make them tolerable. But then you have to host encrypted password blobs yourself, ensuring availability and providing a secure method of syncing between devices. Most people are not capable of doing this/do not have time, so they store them with a third party service which can screw up like LastPass. They're a necessary evil.
The fundamental issue here is that most users do not give a crap. They do not understand identity security, nor do they care to. The ones that do care and understand cannot implement effective solutions, because they are surrounded by people who do not. Sometimes we can't even protect ourselves, because services we are forced to use are designed to the requirements of the majority of people who don't understand or care.
This is not a technical problem, cannot be fixed by technical means, and security will never be a solved problem until that fundamental issue is addressed.
Equally many companies push the SSO capabilities in a product for "use convenience" with a total disregard of the resulting impact on security.
Manglement demand this convenience so that the users don't have huge numbers of passwords. Now to a certain extent that does make some sense, password complexity is being enforced and the comes a point where the Post-It note comes back. The more complex a password, the higher the security but greater risk of stupidity. Now if you require 20 complex passwords the ability for most users to remember those diminishes. Now add in scheduled password changes and the average user is even more confused.
Password managers have their place but then you still have the credentials in one place.
There is no easy solution and this belief that a "Passkey" somehow solves it appears odd. If one wants to take login security seriously then how about a Yubikey?
But "What if I lose it?" people cry. We are then full circle where convenience trumps security.
I’m not quite sure why you’re saying SSO is a bad thing? Easier for the user - nothing extra to remember, no or simpler login process. More secure - because there are no new weak passwords. Slightly more difficult to setup, and there will be times where it’s simply not supported.
Where SSO can’t be used, passkeys are a great tool. They effectively turn the whole endpoint device into a Yubikey equivalent plus usually a biometric as the second factor, for (typically) single touch authentication. Really simple for the end user. Recovery is still the hardest thing to manage - but largely the same problems as passwords.
Where passwords are needed, a password manager is mandatory in my opinion. Users just can barely remember enough entropy for even one secure password and haven’t been able to do more for the last 15 years.
"Users just can barely remember enough entropy for even one secure password"
What do "entropy" [a] mean and [b] solve (and indeed what does "secure" mean)? Mostly "entropy" used by IT folks to describe apparent randomness (apparent being the operative word), but in an age of super fast trial and error and wide word rainbow tables it actually provides very little more protection than non-"random" but not obvious long passwords. There are numerous different attacks on password-based systems, each requires it's own dedicated countermeasures, and "entropy" is only one of them against one -- password guessing. Mathematically (consequently realistically) length is (exponentially) key to defence against cracking, but that makes "entropy" increasingly unworkable as human memory doesn't like meaninglessness. Furthermore, placing maximum responsibility for protection in the lap of the least informed of the hazards, as we have for decades done, doesn't make much sense.
An absolute reality is that passwords have their place but it's not everywhere, but that to be effective where they are appropriate they have to be non-obvious to the adversary but memorable to the legitimate user. Relying on "password managers" as a security measure (as opposed to just a legitimate convenience) merely sidesteps two issues -- [a] maybe passwords are inappropriate in some contexts, and [b] concentrating multiple credentials in one place creates a clearly identifiable target for attack. But where passwords are appropriate, it is the duty of those who understand the risks to impart them clearly, correctly and effectively to those who have to create their own passwords and to those whose duties are providing the ancillary countermeasures across the network. So let's stop just banging on about "entropy" and start addressing the realities.
I completely agree the whole construct of password as a user selected string stored in their brain that they can regurgitate accurately on login is now completely broken, at least where you need to protect against offline attacks (e.g. virtually all the time). Humans will a/ not select passwords with high enough entropy and b/ if they somehow manage this (or secure passwords are dictated to them) - they will not be able to remember them reliably or at all. This is not their fault; our brains are not built this way.
“Banging on about entropy” to users is indeed pointless. They don’t and shouldn’t have to know what it is. However, it is a useful and well defined concept from information theory - intuitively, actual randomness - when discussing password system security with professionals.
If there are better options than password based authentication they should be used. Unfortunately they are often not available, usually due to legacy systems or third party services that are impractical to replace. Which means ensuring there’s enough entropy in passwords, and not sharing them across services.
Humans won’t do it, so password managers should generate unique per service passwords - very long, truly random passwords with arbitrarily high entropy. The user never sees them. The only thing the user needs to remember themselves is one password manager password. If they can’t manage this, they certainly won’t be able to manage more than one. Password managers will generally do a good job of stretching passwords to reduce needed entropy (OK - LastPass screwed up badly here); usually much better than most services.
Centralising passwords does create risks, but I can’t see any other option.
If your users still “create their own passwords” you are effectively doomed.
>I’m not quite sure why you’re saying SSO is a bad thing?
It's not a terrible thing, but it is putting a lot of eggs in one basket. To some extent, that's difficult to avoid; properly securing a lot of independent baskets is extremely difficult, and likely to result in at least some smashed eggs. But a SSO system is pretty complex.
I prefer using a password manager where the archive is only ever decrypted locally. It's still one basket, but it's a comparatively simple system (i.e. smaller attack surface) and I am capable of reliably remembering one extremely-high-entropy password. Of course, the device could be compromised, or the implementation could be flawed, but under those assumptions there's no system that's safe.
As for biometrics, I don't like the concept. It's like having one password, that you leave everywhere you go, and that you can't change. Stealing biometrics is technically difficult, but technical difficulties are liable to be overcome as technology advances. I prefer breaking security to be mathematically difficult. Still, they beat using your birth date as password, which is what most people do in practice, so...
Yes, education. But not "training". The key to success is explanation rather than just rules. When I undertake "user awareness" the first question I ask is "what is your password for?". I've lost count of the number of answers on the lines of "to give me access to the network" (witness the prevalence of "letmein" as a password). Of course it's not -- it's to keep others out of the network.
And as to hardware tokens, as often as not they're stored in a little pocket in the laptop bag so both can be stolen together.
The key failing is not getting users on board with the real issues by failing to explain their wider context, as they're not immediately apparent to non-technical folks, particularly those who haven't been informed about the wider business implications either. But both management and corporate "IT" are notorious for merely issuing diktats rather than explaining anything. Hence they create their own problem.
Hardware tokens aren’t primarily designed to protect against physical attacks. They’re there to protect against remote ones in a way that is resistant to endpoint compromise. This is very useful when you’re being hacked from halfway around the world, and may be worth incorporating into your explanations.
Encryption of the device should be more than sufficient to guard against your scenario.
Increasingly, trusted compute and biometrics built into endpoints provide similar capabilities and guarantees.
"Is this because its more effective than solutions involving mobile phones? Or is its security so bad that no-one dare mention it."
Yes.
The problem is if you lose the card who will issue a new one the same day, setup and ready to use with all the existing accounts?
Even my bank can take a week to post out a new card, so while secure it breaks an essential online service if you ever lose your card, which for bank cards is the time you need that service most, which is why banks have mostly now moved to other methods such as dedicated apps. For all other services they would all either need their own individual cards, or need to share one card, both of which can then become another security nightmare to manage both for users and the services.
Personally I'd put enhanced security ahead of temporary disruption (and If I lose the card, that's down to me causing any problems in the first place. Theft is a different matter). Often it seems to me that banks are penny-wise and pound-foolish; they skimp on basic customer facilities, then spend ages sorting out problems (usually on the phone, with a labrynthine access system and security precautions that make you lose the will to live). I regard it as up to me to have backup plans, on the basis that all banks mess up from time to time. Concerned that my backup bank refuses to issue me with a card, relying on passwords and ringing a phone number.
I don't have a mobile phone, partly on account of the privacy issues, partly because its not important to my particular existence (and partly to make it impossible for SWMBO to issue instructions when I'm not at home!). But in any case I would be concerned to use a mobile for sensitive/private things; I've read of a number of ways to get past phone security in these pages, but none about card readers.
These "cybersecurity leaders" are they in the room with us now?
In my unfortunate expereince 'cyber security leaders' are people who specialise in (half baked, probably AI generated) LinkedIn article writing, speaking at conferences (repeating similar AI generated fluff, or selling on behalf of a tech vendor), but generally knowing fuck all about how things work at the coal face.
Operation cyber security people are too busy to arse around with that nonsense, generally looking haunted and avoiding burnout after yet another incident casue by a vulnerability that was flagged about 15yr ago but no one will mitigate or by an exec who insists on clicking every dodgy link he gets emailed but is too important for training.
What is the point in banging on about phishing proof MFS Vs 'trad' MFA when getting budget for any MFA is still a fight to the death.
We can't get patching right yet. It's the only update to W11, it lets the unpatched W10 vulnerabilities to be closed and taken over by W11 migration risks with new target dates.
And we're probably still hiding the XP box which runs some mission critical system but the vendor refuses to update. But they're a monopoly supplier so you can't go elesewhere or stop using it.
I keep saying this but - Do Not Use An Email Address As A User ID For Anything Other Than Email.
Why?
Because it then becomes the user's universal login everywhere. If they also use the same password everywhere - and you've not way of stopping them because you've no way of knowing - then if one place where they use them gets breached then that's open access everywhere else. The one thing you can enforce is a unique ID.
There's plenty of choice.
I pick an account name - 0laf perhaps - and then I pick a password, and then I give my email and/or phone number as a way of performing a password reset; but unless the backend system is breached, the attacker doesn't know my email, because it's not used as part of the login process. It's not much better than using an email, because of course people may very well use the same username all over and about the place.
The problem is, of course, that people are reluctant to remember even one username/password combination and would really much rather rely on the "stay signed in on this device" button. I have lost track of the number of people who's passwords I've had to reset over the years because their laptop/phone/workstation took an unexpected smoke break and they had no idea what their password and/or username was for half the things they needed to use every day to do their jobs.
You seem to be fighting against most of the internet here, as most services don’t differentiate between username for authentication and email for communication. They want both, and usually want to validate the email address. So for starters, implementing your policy requires a secure forwarding infrastructure that enables users to set up service-specific email addresses on demand.
How are you planning to enforce that they are not reusing their email address across third party services? It might be possible by scanning their email to identify messages from popular services, I guess, combined with some kind of process to chase them up.
I’ve never come across any organisation that does the above. The primary problem here is the reuse of credentials across services. It would seem easier to educate the users on not doing this, and providing password managers to help, than on making them create and track service specific emails. Better still, where possible, setting up SSO.
There's also another problem, which is that email addresses are not forever.
At one point, I had to switch email providers, and I changed my primary email address, and eventually lost access to my previous address entirely. It was a bloody nightmare; for some services, I was unable to regain access altogether, and had to make new accounts.
If you allow the user to set their own username, they will almost always choose an ID that's not at all unique and for a good reason: the unique part should be in the password. Anyone who does that will have the same level of security by doing that to their password. Anyone who doesn't isn't going to miraculously do it because you require a username.
Fine then, we'll choose usernames for people and require them to do that. I've had a couple services like that. Here is the username I was issued by one of them. If you can identify the service that did that, have fun trying to log in*. The username is: iat2riyowj35pn27
If you're going to give someone a random, non-hashed, non-secret username which they are going to forget and need sent back to them in plain text, you'd be better off having an extremely strict password policy instead. They'll be similarly annoyed, but at least the random part would be attached to the thing you're not storing and sending.
* Not only does that account not exist, nor does the service.
It is all about risk management. Always has been, always will be. We often use the word security but again it is just risk management. IT Security is just a focus of risk management. IT security is a supporting part of the overall business. As an earlier poster mentioned, a lot of people have been looking at this issue. If it were easy as some posters allude to, this would be solved. Its not easy. The hardest parts are getting non-risk managers to understand the risks and getting risk managers to understand there is no 0 risk solution. The solution will always be a compromise of the two extremes. A door is a door. Not matter what I do that door can be opened as that is the function of the door. I as a security professional will work with the system(s) teams and owner to secure that door as best as possible. At a certain point I will hit a wall where the "juice isn't worth the squeeze" and so there will be a level of risk. Further more, there are other items other than the door itself the come into play as I hit certain resources costs. If my door is protecting a room with a half wall there really is not much of a point in investing in the door security. I can ask for an full length walls, floor to ceiling but the nature of the activity going on may require half walls. So then the question becomes should we still perform that activity or not. I don't own this. That decision must be made by the owner(s).
I do highly promote multifactor authentication (MFA). But that can cost a lot of money. So lets say you are running a forum with your gaming buddies for player vs player (PvP) games and you want to have an area where you can discuss strategy that is secure from your rivals. You have no real budget and its not really state secrets. You want o make it a challenge but you are not looking for a fortress because you have no budget. A simple forum with user ID and password fits the goal. Is the risk worth adding an investment to get MFA. Many of us would says no. But some may say yes. That is the business owner's decision.
On the other hand, if the system contains personally identifiable information (PII), sensitive personally identifiable information (SPII), state secrets/sensitive proprietary info, personal health information (PHI). Two factor authentication (2FA) is a minimum and MFA is preferred. If you can't afford this then you need to go back and look at your business model. It may not be viable and halting the activity is you best solution if you can't reduce the risk. Its not just a $$$ calculation. Reputation is involved. Not performing due diligence is a lawsuit waiting to happen. A permanent court record is now available to the public. Screwup big enough and you become a household name; to avoid.
Always manage your risks.
They would, of course they would. But...
It's bad practice to use the same secret credential for more than one account, so there'll be millions made by key ring manufacturers as passkey dongles proliferate for every user. And even if the single passkey unlocks a "password manager", not only is it a single identifiable point of attack, but each end application will still be dependent against attack on a password of uncertain quality (and given modern attack methods the bar must be set very high). Realistically, password managers are a convenience, not a security provision.
I feel like you have not worked in a large enterprise environment. I could be wrong, I am just providing my viewpoint based upon your comment alone. SSO is a very common practice in large enterprise environments as necessity for keeping overhead manageable. While isolation (I am interpreting your comment to mean that) can have some benefit with higher risk items. You can introduce new risks by making the individual systems too overhead heavy and open to mistakes or abuse. You are replicating the same activity across multiple systems increasing the cost/complexity. Lets take a basic scenario. I have an employee who is severed from the company. How do I know what systems they had access to and how can I see that the access has been terminated? I need some level of centralization as my business grows in employees/applications/complications. With SSO I can reduce the overhead and combined with MFA greatly reduce the risk of a compromised account (this a larger discussion). When I terminate the account I have terminated all access. Period.
SSO with MFA is not zero but a low risk. If something I have needs further protection I can use additional measures including silos but each of these adds more complication. I have to decide if that is worth the risk.
"so there'll be millions made by key ring manufacturers as passkey dongles proliferate"
I think you may have misunderstood passkeys. There is usually no separate dongle - just a set of per-website keypairs (credentials will never be shared across accounts). Private keys are encrypted under a key stored in a device secure enclave/TPM. The public key is registered to the website. To authenticate, biometrics authorise the client enclave to sign a random challenge from the server. The OS cannot access the private keys within the secure element/TPM, which is also tamper resistent so they cannot be easily extracted even with physical access.
Occasionally a separate dongle like a Yubikey is used instead of an integrated enclave/TPM. It can similarly store many individual passkeys - 100 on the latest, based on a quick Google.
https://www.passkeycentral.org/introduction-to-passkeys/
I have read and reread this stuff multiple times and I still don't quite get it for me:
* I use a password manager with a long master key phrase;
* I have two Yubi keys registered to the password manager;
* Over time I have upgraded my accounts to use 16 random characters;
* I have 4 devices
From reading https://www.passkeycentral.org/introduction-to-passkeys/how-passkeys-work, this stands out:
"When the user installs the password manager on a new device, their private keys are synced to the new device. This allows the user to sign in to their online services from their new device."
Ok, so you need a password manager - check. I store the keys with that ok - just like passwords...
But then it goes on to say I can use biometrics (cannot fully - not all my devices have a reader) or a PIN...
A PIN? Most PINs use 4 digits - maybe 6 - how is that better again?
So I have replaced 16 character passwords with a random (hex?) private key - maybe SHA-256?? - ok. So If I make my passwords 32 random characters does that beat SHA-256 64 hex characters?
There must be something I am missing here - something that just hasn't percolated through - can somebody explain?
It breaks down for me when there are multiple devices.
Your setup is similar to mine. If you're using it with discipline, password authentication through a password manager is pretty damn good. Discipline means at least:
a/ Generating long enough random passwords, including remembering to change the settings back after an ancient website insists on 14 characters or less with no special characters
b/ Never turning on autofill, as it makes you completely dependent on your password manager's heuristics against keyspill attacks
c/ Always validating you're not about to fill a key onto a website it doesn't relate to (e.g. subdomain controlled by a different party)
d/ Never copying and pasting passwords because a service's broken design means you need to enter them for a domain different to the one they were saved for
e/ Setting a short session timeout, and checking for USB keyloggers every time you enter your master password/unlock PIN
f/ Never using a known non-compromised endpoint, as that will compromise all of your secrets at once, not just active sessions
I wish I could say I consistently do all of these; if I'm honest I don't. These problems largely exist because we're trying to graft secure authentication onto non-standardised systems originally created for a thoroughly broken authentication model (manual entry of passwords stored in a person's head into webforms not designed for automation) and it is fragile.
Passkeys are a clean redesign from the ground up, using asymmetric cryptography, keys stored in trusted enclaves that are never visible to the OS even during signing, and an interaction model that eliminates phishing. They're supported by most major third party password managers as a new type of authentication if you want to share between devices, so in my opinion using them for sites that support them is a no brainer (and is what I do with Bitwarden). For the average user, who is using passwords really badly, passkeys are a *massive* step up.
The 6 digit unlock is not an issue because the authentication is local and to the trusted enclave, which can implement exponential timeouts or lockouts to resist brute force attacks. The scenario is more akin to online authorisation of high-value payments than offline attacks on passwords, and those use only 4 digits (though I'm happier with 6). The main problem with PINs is that they're entered through an untrusted interface (e.g. the touchscreen shared by a potentially compromised OS) rather than an interface used only for authentication and bound directly to the secure enclave (e.g. biometric sensors), but this is independent of the secret length.
"I wish I could say I consistently do all of these; if I'm honest I don't. These problems largely exist because we're trying to graft secure authentication onto non-standardised systems originally created for a thoroughly broken authentication model (manual entry of passwords stored in a person's head into webforms not designed for automation) and it is fragile."
Bingo. Upvote for that. We can't always fully control our risks and despite reservations, we have to accept risk because of requirements to interact with a non-standard system. In the rosy colored world everyone uses the same standards and implements them in a consistent way. However, in the real world that just does not happen.
Its a bit like driving. We have standard signage but the standards can change by geolocation. Furthermore, individual drivers will do what individual drivers will do. I see someone driving unsafe I try to avoid them but sometimes I have to follow their path and add more buffer (distance between cars for example). I have to accept the risk but I still drive defensively within my means.
