Worries Arise About Security of New WebAuthn Protocol (zdnet.com)

An anonymous reader writes: "A team of security researchers has raised the alarm about some cryptography-related issues with the newly released WebAuthn passwordless authentication protocol," reports ZDNet. "The new WebAuthn protocol will allow users of a device -- such as a computer or a smartphone -- to authenticate on a website using a USB security key, a biometric solution, or his computer or smartphone's password." But researchers say that because WebAuthn uses weak algorithms for the operations of registering a new device, they can pull off some attacks against it.

"If converted into a practical exploit, the ECDAA attacks discussed in the article would allow attackers to steal the key from a [server's] TPM, which would allow attackers to effectively clone the user's hardware security token remotely," Arciszewski, one of the researchers, told ZDNet. "The scenarios that follow depend on how much trust was placed into the hardware security token," he added. "At minimum, I imagine it would enable 2FA bypasses and re-enable phishing attacks. However, if companies elected to use hardware security tokens to obviate passwords, it would allow direct user impersonation by attackers." Attacks aren't practical, and experts say the root cause relies in badly written documentation that may fool some implementers into supporting the old algorithms instead of newer and more solid ones. The FIDO Alliance was notified and has started work on updating its docs so it won't look like it's recommending ECDAA or RSASSA-PKCS1-v1_5. "PKCS1v1.5 is bad. The exploits are almost old enough to legally drink alcohol in the United States," Arciszewski said.

Comments

Question for you security experts

[thegarbz]

If algorithms are known to be weak, why are they included in new standards? Are they expensive or are there compatibility reasons why we don't implement the "best" in the newest standards?

I know nothing about this, but the way the summary was written would imply only the registration of the devices is weak, does that mean the actual authentication uses a strong algorithm?

Re: Question for you security experts

[Anonymous Coward]

Because the standard is effectively written by Google

Re:Question for you security experts

[Anonymous Coward]

Because no actual experts were involved in making the standards.

This is the usual case when "web"-anything is involved, as evidenced by, for example, the entire works of the W3C.

Re:Question for you security experts

[Anonymous Coward]

Mod parent up.

The industry's dirty secret is that they have retards making up most of these so-called "standards".

Re: Question for you security experts

[Zocalo]

In part but, as with most security SNAFUs where people really should have known better, I'm also wondering how much involvement the intelligence services like the NSA, GCHQ, etc. may have had behind the scenes. It's well documented that governments have been looking to get backdoors in secure web protocols one way or another (legislation being the means du jour), and what better way to do that than with an end-run around the whole problem by compromising users' accounts and simply acquiring their login details? Sure, the researchers might be claiming that some of the attacks are not really practical for typical attackers, but the NSA etc. are not really typical attackers, and especially so since they have things like NSLs in their toolbox.

If so, it's good to see that they are *still* only paying lip service to the notion that if only $friendly_governments has knowledge of the backdoor and necessary computation resources, then it's just a matter of time before $not_so_friendly_governments, $very_unfriendly_governments, $cyber_criminals, and (eventually) $every_script_kiddie_and_their_dog will have the necessary knowledge and resources too. Perhaps they think Snowden was a one-off or something?

Re:Question for you security experts

[Anonymous Coward]

I'd answer, but the NSA goon behind me is prodding me to move onto the next article with his rifle barrel.

Re:Question for you security experts

[Anonymous Coward]

I guess for legacy systems. It is not because the standard allows it that you should use it. Also some companies have really outdated procedures, sometimes mentioning decades old algorithms. This allows them to use the standard. As long as they deploy it instead of no 2nd factor it makes attacks harder at least, so better than not being able to use it due to internal procedures.

Re:Question for you security experts

[Anonymous Coward]

My company has asked one of my work friends to join a standards body and he's none to thrilled about it. Don't know how normal that is, but I wouldn't be surprised if there's a few people who truly care about it, a few people who join for the power trip aspect of getting to tell everybody what to do, and a whole lot of people who are there because the company they work for required them to do it.

He described it as the most boring and tedious thing he's ever done. Just people constantly bickering about minutia.

Re:Question for you security experts

[Anonymous Coward]

Teehee. Goon. The NSA is all pasty neckbeards like us.

Re:Question for you security experts

[Anonymous Coward]

Just people constantly bickering about minutia.

Not to bicker about a minutia, but you probably meant "minutiae".

Re:Question for you security experts

[AmiMoJo]

From TFA:

"In subsequent email exchanges with the Paragon team, ZDNet understands that at the heart of the issue may be the confusing WebAuthn documentation released by the FIDO Alliance team, which, for legacy purposes, categorizes both algorithms as "required" (for RSASSA-PKCS1-v1_5) and "recommended" (two ECDAA-based algorithms)."

TL;DR they adopted an older standard to avoid building something from scratch, and there is some old and poorly worded advice in the documentation.

Re:Question for you security experts

[Anonymous Coward]

Parkinson's law of triviality, also known as bikeshedding, in full effect. I've seen it in full effect at multiple places. I've seen it in situations like this, including technical standards, budgets, evaluations, and more. However, my favorite was a literal argument over the color of a bike shed at a zoning meeting.

Re:Question for you security experts

[Anonymous Coward]

And rifle barrels aren't usually warm and squishy...

Updateing the documentation

[Anonymous Coward]

I hope the update is "implementations under all circumstances MUST prevent use of know insecure methods like ECDAA or RSASSA-PKCS1-v1_5".
Everything less is a joke for a brand new protocol essentially nobody is using yet.
And yet people still don't seem to get why WireGuard will support one and only one algorithm.

Why this "war on passwords"?

[Anonymous Coward]

Yes, I know. It's easy to choose a weak password. And then you write it with a sharpie on your smartphone's back and things.

But there is one enormous advantage to a password: it's in *my* head. When I pass away, then it is gone too -- unless I've left a copy to someone I trust. This is a feature I won't give up on.

So: use a password generator (that's the only way to really put a controlled amount of entropy on that). Fucking memorize it (the first times it seems impossible, but my most important three to four passwords, like HD LUKS password, backup encryption are pwgen -n 16 -- no problem memorizing that after a modicum of training).

Don't trust schemes like this that *make people dumber*. Rather make people smarter.

Re:Why this "war on passwords"?

[ledow]

The memorisation thing is always used as an excuse.

You want to memorise it? Set your important passwords to it. Make yourself type it in a thousand times a day. Guess what, you'll be able to screw up the piece of paper with it on by next week because you'll be so frustrated at having to refer to it and you'll have typed it so often that you'll get it stuck in your head.

The problem with it being just "in your head" is that if you're hit by a bus and forget it - all your stuff is gone forever. Even though you may well require access to it to continue with your life.

Re:Why this "war on passwords"?

[grumbel]

The problem with a password isn't just that you have to remember it, but that you give your secret away every time you try to log in to a service. So if there is a man-in-the-middle or you just accidentally entered the password into the wrong server, your password is now compromised. There are plenty of better ways to do authentication that don't require exposing your secret.

Re:Why this "war on passwords"?

[Anonymous Coward]

The human brain can't scale that to the number of security domains required (you do use a different password for EVERY online account right?). And after that you need a password manager, and then you start to see single-point-of-security-failure which non-password based identity systems are trying to solve. This whole "I keep it in my head" idea is security for toddlers who don't need security.

Re:Why this "war on passwords"?

[Megol]

So why exactly didn't the hypothetical person store the paper (or a copy of it) in a secure place instead? Bank, at home hidden or in a safe?

Re:Why this "war on passwords"?

[Anonymous Coward]

> he problem with it being just "in your head" is that if you're hit by a bus and forget it [...]

Yes, but exactly this is *the* feature. My head is gone, the credentials are gone. Unless I take provisions towards the contrary. That's exactly how I want it to work.

Re:Why this "war on passwords"?

[Anonymous Coward]

This is why password managers exist. THe password you need to remember unlocks the manager.

Re:Why this "war on passwords"?

[thegarbz]

Set your important passwords to it.

Passwords... plural. You just failed security 101.

Re:Why this "war on passwords"?

[bluefoxlucid]

Then: someone decides your password must have 1 upper and lower case letter, 1 number, and 1 odd-looking thing, with 8 characters, and change every 30 days.

Re:Why this "war on passwords"?

[Anonymous Coward]

Because passwords are awful for security in essentially every respect except for them being the most flexible and easiest to use access control mechanism. I'm sure I'm missing some reasons, but here's a few off the top of my head:

• Remembering good passwords is hard, in practice requiring a password manager to make them actually secure... at which point you've lost the main benefit of using a password over something longer than a human wouldn't be expected to remember/enter anyway.
• Not accidentally giving away your password is hard. To be secure, you have to use a different password for every different site and never accidentally enter your password for one site into another. Once again, practically impossible to do without a password manager.
• Related, to the previous point, passwords are symmetric in the sense that knowing how to verify a password is the same as knowing the password. (In practice, good actors use hashes, but we're not trying to be secure from good actors.) This means it's really easy to accidentally give away a password in a way that you can't accidentally give away a private key.

Re:Why this "war on passwords"?

[nasch]

Rather make people smarter.

How do you propose to do that?

Re:Why this "war on passwords"?

[omnichad]

They didn't say their whole head was gone. Just that password.

Re:Why this "war on passwords"?

[Anonymous Coward]

um, HTTP Digest AUTH?
Yes, it needs an algorithm update, but doesn't require you to give away your secret.

The problem is server-side applications, not passwords.

Re:Why this "war on passwords"?

[tepples]

In HTTP Basic or Digest authentication, how does the protocol let the user log out and return to an unauthenticated session?

Re:Why this "war on passwords"?

[ledow]

Depends.

Are you really stupid enough to think that having unique passwords for absolutely everything gives you security?

Or you do you believe that two services which basically access identical amounts of information about you can happily share a password because any breach of either only means compromise of the exact same information / access?

For example, I really don't care that my Slashdot password is the same as other web forums where the worst that can happen is someone posts something under my name. I really don't want a unique password for every single one of dozens of such "unprivileged" accounts.

Thus I *tier* my passwords. These ones let you do X, these let you do Y, these let you do Z. At the highest tier, yes, unique passwords per service because of the import of the access gained from them. But ALL THE OTHER tiers? Not so important.

People who suggest you should memorise a thousand passwords or store them all centrally (e.g. password management software) are a lot more stupid and out of touch with reality than those that say "Have a consistent password for such services".

Hint: When you lose your password, it's really easy. What access does that account have? Therefore it must be one of Tier X passwords, therefore it's not going to be a chore to remember what it is. And a damn sight better than typing in your OTHER passwords thinking "Well, I must have used that then" into what might actually be a compromised website.

P.S. The reason that NOBODY, NIST, NSA, GCHQ, etc. recommend that you don't expire passwords any more (and there's been an article on here from "the guy who set the rules for passwords" saying the same): Give people too many passwords and they destroy the security of them in order to satisfy their own convenience.

A set of tiered passwords shared across services which can't give any more access than ANY of those services already gives up from that password is no worse. At absolute worst, it means you have to reset a couple of passwords if one is compromised, instead of one.

Security has to meet reality every once in a while. Pouring concrete into your car and chiselling it away every morning means nobody will steal it, yes, but it's so inconvenient as to be impractical which means nobody will ever do that.

Re:Why this "war on passwords"?

[Anonymous Coward]

pwgen -n 16

pwgen -s -n 16 would be better. Since these kinds of passwords are only generated once every few years, and are extremely important to my security, I usually take more drastic steps, like using physical dice to generate a truly random password. I use three six-sided dice (two white and one black) rolled simultaneously. The two white dice generate one character in the set a-z0-9, and the black dice selects whether the letter is upper or lower case depending on if the die is odd or even.

Re: Why this "war on passwords"?

[Miamicanes]

Rules that blindly enforce arbitrary combinations of specific characters piss me off to no end.

A rule that passwords must have an uppercase letter adds, at best, 1 to {len-1} bits of entropy. Rules that mandate 1+ digits add (at best) another bit of entropy (1/4-1/2 bit x {len-2}). Ditto for "special characters" if the set of acceptable characters is limited to a subset of those in ASCII that can be directly typed, as opposed to "any unicode value".

If any rule has to be enforced, it should be based on some total number of bits, based on the fewest-possible bits that could plausibly represent the character... adjusted downward for more-guessable characters. Say, 100-128 bits minimum. For example:

* Password is all-lowercase or uppercase Latin alphabet: 5 bits/character, 20-26 chars min.

* Mixed-case Latin alphanumeric, possibly with symbols commonly found on US-layout keyboard: 6 bits/character, 17-20 chars min.

* Everything else: (total UTF-8 bytes) x 6 bits (ex: 10 Cyrillic letters, 5 Chinese characters, 8-9 Hangul jamo, etc)

* Modifiers: each recognized dictionary word or word found on list of hacked passwords (after normalizing digits/punctuations to L33t-speak) reduces entire sequence of matching characters to 16-20 bits (the size of the dictionary)

* Chinese & Kanji characters on the "must learn to graduate high school" list for their country are counted as 10-11 bits... 9 if they're among the 500 most common, 8 if they're among the 100 most common. Alternatively, for simplified Chinese, count 6 bits per Wubizixing keystroke & use smallest calculated value. So someone in China using only common characters might need 10-15 to meet a 120-bit minimum.

Re:Why this "war on passwords"?

[Anonymous Coward]

Corrupted credentials is the most common option. There are a couple ways to do this. Your logout page can call an XHR with set credentials (e.g. https://logout:logout@website.example), Or it can call the ClearAuthenticationCredentials (or something like that) API. Or, you can have that page present a 401 response with the same realm, which, depending on the browser, doesn't always stick in history. Or you can write your application correctly.

Really, the best idea is to have the logout page void the session, then redirect to the login page. Since the login page is in the same realm AND present in your history, it will stick in the major browsers. Regardless, for proper security, you should check for a valid session on every page on your application, and, if there isn't, redirect people to the login page (if you want to keep track of where they are going next, set that as a cookie so the query string isn't cluttered). The login page, in turn, should always present a 401 challenge, a 403 forbidden on too many tries, redirect to itself with a noisy query string, or a redirect to the proper page on success. Using this method, you will get the log out to stick for pages in your history on the major browsers and protect your users for the ones where it doesn't.

Re:Why this "war on passwords"?

[thegarbz]

Are you really stupid enough to think that having unique passwords for absolutely everything gives you security?

Something giving security. You just failed security 101 again, and looked quite the fool calling someone stupid in the process.

For example, I really don't care that my Slashdot password is

So maybe you have a different definition of "important" (your words not mine) than I do.

At the highest tier, yes, unique passwords per service

Cool so we are in agreement. Next time be more verbose and just paste this in the reply box rather than giving poor security advice publically and hoping others will read your mind to get the complete picture.

Re:Why this "war on passwords"?

[tepples]

Really, the best idea is to have the logout page void the session, then redirect to the login page.

HTTP Basic or Digest authentication doesn't store a session ID. A site could store a session ID in a cookie, but in the past, people recommending HTTP Basic or Digest authentication to me have done so on grounds that they don't want any cookies, not even first-party ones.

Re:Why this "war on passwords"?

[Anonymous Coward]

I understand that part. That is why I gave you the best option. At a minimum, redirecting to a page that is already in their history and having that respond with a 401 will force re-identification on the entire realm. It also voids credentials on the other pages in the history for most major browsers. The problem is that HTTP Authentication doesn't really have an idea of state, sessions, or logging out. When you were done, you closed your browser, which then forgot your credentials; the server forgot about you the second it wrote the final response byte to the buffer. You have to keep in mind that it predates wide-spread cookie use and plaintext passwords weren't seen as a problem, and you had to re-authenticate for every request in the realm. Short of someone changing the RFC, any attempt to logout and force it to stick is just a hack around the standard and the different way browsers interpret it.

RSA bad?

[Anonymous Coward]

Wait. RSA insecure? I doubt it. Not, at least, until high-qbit quantum cryptography becomes a reality (and enough accesible outside labs).

Of course, RSA needs more than just pure RSA, and hash algorithms and padding systems needs to be strong. But I see too much confidence into elliptic curve vs RSA and I suspect that it's more because EC is more recent than to be more solid.

its the encoding NOT algorithms

[johnjones]

the algorithm is fine its the encoding... i.e. this RFC which to give the authors credit they updated...

To be honest I suspect that this was driven by hardware and the "standard" defines other algorithm's so its simply a case of getting rid of that combination
Its a good thing that people are auditing these before they become enshrined and I hope WebAuthn becomes stronger because of it

  WebAuthn is so so much better than the current in place alternatives... we really really needs to give an alternative to the password that is widely adopted

regards

John Jones

Re:its the encoding NOT algorithms

[Anonymous Coward]

The could link webauthn to classic certificates because they are directly available and even we could use today as SSL option.
But, for some reason, browser developers (MS,Google, Mozilla Foundation...) has removed signature functionality without develop an alternative and WebAuthn seems to go into the same logic pushing new hardware without put an option to use classical cryptographic standards ( RSA tokens, PKCS11, CryptoAPI on Windows...) from the same WebAuthn.
It seems that they try to destroy PKI instead of create a true replacement of passwords. PKI is available now, altough WebAuthn could add PKI as an option. But It seems that they don't want to do it and It seems even probably to me that if they are success, they will try to kill PKI later supressing SSL client certificates as a authentication system in a future when WebAuthn was well adopted.

PKI authentication and signature directly available on Browser should be a high priority functionality, but they refuse to do it. Why?

Re:its the encoding NOT algorithms

[nasch]

How is the encoding the problem? Generally encoding is not a security measure, but an interoperability measure. If you're relying on encoding rather than encryption, that doesn't sound like security at all. Maybe I'm misunderstanding something.

What's Their Number?

[mentil]

The exploits are almost old enough to legally drink alcohol in the United States,

Exploitability is the #1 thing I look for in drinking buddies.

Re:What's Their Number?

[Anonymous Coward]

Yeah. Me too. ^-^

Introducing the WebWebn! Now with WebWebnAuthn!

[Anonymous Coward]

Do your web apps also still run too fast?
Do you hate using well-established platforms with APIs that were refined for decades years?
Do you want more remote-execution of completely unknown code in a shitty VM disguised as a document viewer?

Then download WebWebBrowser today! The new browser by the WtfWG!
The only browser that runs IN your browser!
The only browser that naturally limits code to 3.141 MIPS, due to the entirely new league of simplicity of its clickwheel-compatible TardScript language environment, running entirely in GNU/Linux JS/HTML5!

The only browser that runs entirely in the cloud botnet. Executing unverified volatile remote code ... IN unverified volatile remote code!
Now with direct hardware access to rings 0 up to -3 (IME), and fully remote-executed authentication!

WebWeb ALL the things!
Apps? ... WebApps? ... WebWebApps!
Sockets? ... WebSockets? ... WebWebSockets!
Hardware? ... VM? ... WebVM!
Authentication? ... WebAuthn? ... WebWebAuthn!
OpenGL? ... WebGL? ... WebWebGL!
Developers? ... WhatWG? ... WHAT THE FUCK WG!

Get. It . NOW!(?)

Probably a legacy system

[MikeRT]

The exploits are almost old enough to legally drink alcohol in the United States,

Now why would you do that, unless you support legacy systems that are positively ancient? It's like all of the healthcare and insurance websites that say you can only use 8-16 characters and provide a tiny whitelist of special characters. Why are those even allowed to be online if that's all they can handle? That's all but an admission you're too cheap to update anything to make it really secure.

Re:Probably a legacy system

[Anonymous Coward]

It's like all of the healthcare and insurance websites that say you can only use 8-16 characters and provide a tiny whitelist of special characters.

Banks are pretty pathetic for this as well. I was setting up a debit card not so long ago, and the teller asked me to enter a 4-digit PIN.

I told her a 4-digit PIN was stupid, and not nearly secure enough. She told me their system only supported 4-digit PINs.

Really? You're a fucking bank, and you are insisting I use a 4-digit PIN? Who the fuck is doing your security?

The sad reality is, most companies put in weak security and then wash their hands and say "well, your PIN was insecure so it's your fault". No, the reason my PIN was insecure is because you idiots don't support real security.

Re:Probably a legacy system

[Anonymous Coward]

Banks are pretty pathetic for this as well. I was setting up a debit card not so long ago, and the teller asked me to enter a 4-digit PIN.

I told her a 4-digit PIN was stupid, and not nearly secure enough. She told me their system only supported 4-digit PINs.

Really? You're a fucking bank, and you are insisting I use a 4-digit PIN? Who the fuck is doing your security?

The sad reality is, most companies put in weak security and then wash their hands and say "well, your PIN was insecure so it's your fault". No, the reason my PIN was insecure is because you idiots don't support real security.

Well, the thing is you're confused about this. They don't need your 4 digit PIN to run the card as a credit card.
I can't remember how long it has been since I had a bank card that couldn't be run as a credit card (notice the MasterCard or VISA in the corner).
All they need is the information printed on the card itself.

Re:Probably a legacy system

[Anonymous Coward]

A 4-digit PIN that is protected by a maximum 3 try limit.
IF (and I admit that is kind of a big IF) it is implemented correctly, you'd have to steal on average around 1500 credit cards to manage to guess a single PIN.
One way to express this: someone stealing 10 cards a day (no idea what is realistic) would have to work 150 days for a single win.
That would only be worth it if you'd manage to steal several thousands of dollars from a card, and you mange to try out those 4500 invalid PINs without being noticed.
That's why 4 digits is considered safe enough, especially since there are much easier ways to get the PIN that work just as well against longer PINs.
Not that banks don't often have horrible security, but this one I wouldn't consider a significant issue.
(now, let's rant about those people encrypting PDFs with a 4-digit PIN...)

Re:Probably a legacy system

[ljw1004]

It's like all of the healthcare and insurance websites that say you can only use 8-16 characters and provide a tiny whitelist of special characters. Why are those even allowed to be online if that's all they can handle? That's all but an admission you're too cheap to update anything to make it really secure.

I think "restrict to tiny whitelist of special characters" sounds like a really good idea. As soon as we delve into variable-length characters, I worry that some (any) part of the stack might not handle them right. Maybe there's code which has the wrong computation about how many bytes a given character takes. Maybe some code is vulnerable to a string which terminates half way through a multibyte sequence. Maybe some code indexes into a string, which you can't do with variable-length.

Yeah it is a matter of cheapness. "Do I want to spend my security $$ auditing every single codepath and library for being safe with respect to variable-length characters, or do I think that a whitelist is good enough so I can spend my $$ on other security matters?"

Even just dealing with capitalization is confusing, in case your business needs involve case-insensitivity. In Turkish there are two forms of the letter "i" and turning something uppercase then lowercase is no longer a straightforward reversible operation -- and if your business needs require case insensitivity (e.g. for names) then the normal programmer techniques for generating a canonical capitalization won't work.

Now if all the stack is written in a language like C# (all characters are 16 bits wide -- unless you're using the newer .NETCore which has UTF8) or a language like Swift (all characters are variable-length but the string library is locked down enough that you won't accidentally do something wrong) then I'd feel mostly safe, so long as I didn't need case-insensitivity. Otherwise, I wouldn't.

You might say "well, coders are paid to sort out these problems". Completely true. And a well-paid programmer will be well-paid because of their experience, and their experience will say "be very careful about allowing arbitrary characters, and only go there if there's a compelling business need that outweighs the disadvantages".

Damn, /. ate all my strike-through text.

[Anonymous Coward]

I thought it supported <s> ... or was it <strike>? Just like what the SlashCode developers' brains are on?

Access to admin privileges

[Sqreater]

I was wondering if this kind of system could be used to enable admin access. Admin access would be enabled remotely from a Microsoft server using two factor authorization, say, and no malware would be able to access admin privileges as this would be the only way to escalate. Made robust, it would destroy malware ability to take over machines by escalation of privileges. It could be a feature across all users, or, an enterprise addition for a fee with the purpose of increasing security for critical systems.

Like how the WPS-PIN standard was badly written?

[Anonymous Coward]

Do you remember? That was the standard that split an 8 digit key, which was actually 7 digits and a checksum digit. into two parts in the protocol, one with 4 digits and one with 3 digits and the checksum digit. The documentation was suggestively written in a way that made implementers check the parts separately and return a right-or-wrong information for the first part separately from the second part, not just for both parts together. This reduced the necessary attempts from 10,000,000 possible keys down to 11000. Yeah, surely that was an oversight.

WebAuthn uses weak algorithms ..

[najajomo]

By any chance, did the NSA help them with the algorithms?

Re:WebAuthn uses weak algorithms ..

[Ronin Developer]

When PKCS#1 v1 and 1.5 were written, RSA Laboratories was working closely with the NSA. At the RSA Data Security Conference, it was made very clear to those attending that they were there.

That being said, PKCS#1v1.5 has been deprecated. PKCS#1v2.1 and 2.2 are out there. PKCS#1v2.0 corrected the major issues with 1.5.

Why TLS is still using the old standard is beyond me other than effort to safely transition to the newer standards. Allowing for a transition to the newer standard while still supporting the older will, likely, introduce vulnerabilities into TLS beyond what 1.5 presents.

So, it claims to be secure and passwordless...

[Anonymous Coward]

But uses passwords and uses weak algorithms and can easily be attacked? Did NSA pay for any of the research behind this or did they contribute some cool deterministic random number generator perhaps?

Sounds like good news

[Anonymous Coward]

The protocol is tight enough that they had to attack the cryptography. That in itself is a win.

Know that regardless of standard, protocol or algorithm, some 2FA device implementations will be poor. There will always be some reliance on brand reputation, and a need to replace devices when compromises are exposed.

As a second factor, WebAuthn seems much better than anything else reasonably available. That said, I would never use it as the only factor.

Re:Sounds like good news

[Anonymous Coward]

> The protocol is tight enough that they had to attack the cryptography.

No, the cryptography had blindingly obvious, 18 year old bugs so they didn't even look anywhere else because that fruit wasn't just low-hanging, it was 6 feet under.

Typical attackers

[Errol backfiring]

NSA etc. are not really typical attackers

I think they are very typical attackers. Kids fooling around won't operate on a large scale. Anyone else does. It does not matter if these actors are intelligence agencies vacuuming up all internet traffic, half-legal copyright "cops", or downright criminal organizations that are only after your *coins and banking details. The main difference is the amount of time it takes for these data to fall into the wrong hands.

That said, it might be perfectly possible that criminal organizations are trying to promote backdoors as well in open standards.