FIDO Promises a Life Without Passwords
HTML-код
- Опубликовано: 19 ноя 2023
- Try IBM Security Verify Access Management → ibm.biz/BdSGaW
How many passwords do you have to keep track of? Answer: Too many! In this video, cybersecurity guru Jeff Crume explains the FIDO standard which eliminates the need for passwords entirely. In addition to creating a passwordless login, FIDO's benefits include resistance to phishing and replay attacks.
Get started for free on IBM Cloud → ibm.biz/ibm-cloud-sign-up
Subscribe to see more videos like this in the future → ibm.biz/subscribe-now
We know you've had a lot of questions about this video. Jeff made his way back into the studio to help sort things out in a new video. Check it out: ruclips.net/video/lRFeuSH9t44/видео.html
For more details on FIDO, you can learn more from the FIDO Alliance here: fidoalliance.org/how-fido-works/
(first link) this.video=video;
Actual link to the correct video: ruclips.net/video/9nrE4t4-IXA/видео.html
could you tell me what app or web app are you using for your transparent board? thanks
Fido is simply public key authentication, something we have since the early 90s and that everybody could have used but nobody wanted to use within the last 30 years; except for UNIX/Linux SSH users. Also it's not really the end of passwords, as if Fido keys are not encrypted, they can be stolen just like if you write your plain text passwords somewhere. Of course, this limits the amounts of passwords to just one but so does a password manager. Yet a password manager can be used with any device and from anywhere, as it requires no external hardware, no USB port or Bluetooth and also no special software support in the system or the browser.
Yes, but they are also trying to tie to your personal identity, biometrics, so yeah nah, I will keep using normal pgp keys and regular passwords
Yeah they tie it to an account - like your Google or Apple or Facebook or whatever but do PKI between these parties.
Not so different from SSO, just with more trust for device level authentication
@@marcopeterson805 Would you have a problem it everything was tranparent and it would all be local on your device?
@@marcopeterson805 was gonna comment that lol ..wellssaid
@marco
The moment he said "biometrics" I said nope, my password is fine
How to handle the situation where phone is stolen or lost...? I guess still need email or similar OTP handling mechanism.
If you lose your phone, traditional account recovery mechanisms are still possible (answers to “secret” questions, etc.) to generate new passkeys after proving your identity or passkeys can be synced across devices, in some cases
Instead of storing private key on a single device it can be stored on an encrypted cloud and the cloud encryption key can be printed on paper and can be kept in a safe. or an application can be built which will allow access to the device key holder only under certain conditions, like contraction and dilation of pupil and retina movement to make sure the person is alive and phone is not being misused, or a fingerprint scanner with pulse sensor etc.
@@jeffcrume Having to have and remember answers to secret questions is worse than having to have and remember passwords - it just requires more sensitive data maintenance. If problem of "lost/destroyed device" won't have a convenient solution - FIDO would have only a limited use in the future.
@@anonymous_1122_ Are you saying that the imperfect solution to a complex problem is not perfect so we should keep things as they are? What is your proposal?
@@anonymous_1122_ Don't answer on security questions by random strings and it will be much easier to deal with it.
"Help. I lost my phone. How do I get my passwords?"
You will loose your passwords but not accounts in that case because of 2FA
Passkeys are bounded with device , in this case you have reregister the device. Every org they have their own process to reregister the device.
@@jeffcrume You mentioned browser support. Where would the private key be stored typically? LocalStorage? Cookies? Very curious to know this since I remember that storing sensitive info on the browser can be trickier than, say, storing it in a mobile app. Thanks for the great video!
@jeffcrume how are they being kept secured on the cloud?
@@muraliavarmathe private key is stored in some kind of a special-purpose secure hardware element on the device that the browser is running on. This element can be baked into the CPU in what’s known as a “Trusted Execution Environment” (TEE), or use a discrete module known as a Trusted Platform Module or TPM. There are good wiki articles on these.
Ive been doing this for over 10 years with GPG though I never gave it a spiffy name. The difference is that when you register, you add the servers gpg key to your ring. The server encrypts with your pub key and signs with its private key, the client validates the sig with the servers pub key and decrypts with the client private key, then encrypts the challenge with the servers pub key and signs with the clients private key before sending it back to the server.
This way the server validates the user and the user has validated it is the correct server.
Ive been having fun messaging my kid directly through TCP sockets but this inspires me to make a server that saves user info so we can talk regardless of if we know each other's IP addresses 🤔💡
Unless you have fixed IP’s, that could be a little cumbersome
@jeffcrume Not necessarily. The server only acts as a rendezvous point for you to share your current IP address with each other. You both send a request to the server and the server responds with the other person's IP at which point it can remove itself from the equation since it's work is complete
did you just invent "dynamic dns"?
@@ivok9846it’s common enough already, has been used in online games.
That sounds a lot like WebRTC in browsers. You have ICE, STUN, and TURN servers to publish IP addresses, negotiate connection details, and if necessary, host a tunnel around NAT.
Not even 3 minutes and I'm amazed by this guy's ability to write on a mirror for us to read HOLY CRAP.
😂 I only wish I was that capable … ruclips.net/video/LdnJoT5IWPM/видео.html
You wouldn't really need to. You can write as normal then in post production apply a filter to reverse the direction.
Good video describing the basics. I think also explaining OTP and TOTP would be great topics.
What im working on distroys this design, i use OTP and asymeyric RSASSA-PSS for signatures. Eliminating the challenge and opening up flows for mucro payments and interoperability.
I really like the way google handles linking your phone's messaging with the web version: You select "device pairing" from the settings menu on your phone and aim your phone (the camera is activated when pairing) at a large QR code on the screen. Instantly they are linked. No password needed and it's really fast. And since only my phone would work, it's secure as well.
Can we just appreciate that he wrote everything in mirror image from his perspective on that transparent board 😮
If only it were true … 😂 ruclips.net/video/LdnJoT5IWPM/видео.html
Are you sure the video wasn’t mirrored afterwards?
And he also wrote with his left hand being a righthanded person! Fantastic!!!
I miss the FidoNet days. Good thing they’re bringing it back!
I appreciate the verification part of this process. It wasn't quite solidified in my mind till this video.
I like how the camera's POV is a higher dimensional view. We see the speaker in a 3rdperson, while viewing his POV simultaneously.
I believe there was an error in the video.
I thought that one would use the receiving party's public key to encrypt the message, and the receiving party use their private key to decrypt the message.
The response to the sender is then encrypted by the sender's public key to be decrypted by the sender using their private key.
The video suggests the opposite, that the encryption occurs with the private key. If that was the case, the encrypted message would be decrypted by anyone holding the public key.
Here challenge is generated by the server using public key which can be decrypted only by private key on the device. Here Asymmetric encryption is used to authenticate like initial handshake of TLS
No message-level encryption is used in FIDO standards. Instead *signatures* are used. Private keys sign challenges and relying parties (websites) validate signatures using the pre-registered public key.
the explanation is theoretically correct, message encrypted by private key do require public key to decrypt.
Your concern might be that in most case the message to be encrypted is a unique value, or digital signature for proofing the identity of the key owner, and not for encrypting secret.
But in the video it is to respond to the challenge from the server, and it does no harm for anyone to know who you are (decrypt with public key) since you proof it without revealing your private key, which is still a suitable use case.
The flow is right, but at that step the message is signed rather than "encrypted" . Only the correct sender with access to that private key could sign the message. Anyone with the public key can verify the message. However, the reason for the step is to verify that the message originated from the correct sender, so it is fine if anyone with the public key can verify that.
Noe that the unencrypted challenge originally sent by the server is generally also required for this verification step to occur, and that is not available to third parties outside the client / server.
You can verify someone knows a secret that is known by both parties. In this case the challenge is the shared knowledge. It is encrypted with the user’s private key. The server knows both the challenge and the public key, so it could verify the contents of the response.
This is a great video, I have heard of FIDO but never researched it at all, thanks so much!
You’re very welcome!
Absolutely love this. Going to set this up in my lab.
Good luck 😂
I think that on top of that, the communication from the server to the client should be encrypted with the private key of the server and the responses from the client should be encrypted with the public key of the server. This way each side proves its identity to the other side
Yes, TLS/SSL will handle this
This is an excellent video and the security concepts around FIDO explained here are articulated excellently. My question is this: If FIDO has been around since 2013 why hasn't this seen more adoption to prevent hacking and cyber security incidents? If we're getting rid of passwords does this completely get rid of social engineering tactics? Is this solution solely focused on end users that access systems over the internet? What if I access a system from a device that I didn't use during the initial registration? Some websites like gmail use IP information to block users from logging in if their IP changes, granted using different devices from different networks changes the IP of the device.
I’m really glad you liked the video! Good questions: 1) FIDO2, the newest version, adds some capabilities that I think have gotten many off the fence but the bottom line is that vendors, web site operators, etc., typically need a business justification for such changes and it has taken a while for them to realize just how messed up the password-based system was - inertia is a tough thing to overcome. 2) We will never get rid of all social engineering attacks but this technology certainly helps with the ones that are focused on stealing passwords (which won’t exist to be stolen), but attackers will more on to other forms or social engineering. 3) FIDO is for end user authentication, as far as I know. 4) It’s really not a good idea to logon from a device you don’t control in the first place. There could be a keystroke logger installed that would capture sensitive information
Hey, I think you can login through a system with which you might not have registered by possessing the device you registered with. For eg. You want to log in to your computer and you have setup your passkey on phone, you can absolutely do that! You just have to have your phone around when doing so.
Don't worry. Cybercrime will evolve, for example, to the implantation of nanobots to steal neural information or to control a person's nervous system. Strange times are coming.
It also isn't much help agaisnt MITM, mind you neither are passwords
FIDO wasn’t popular because the users controlled the keys. Now that the capitalists can store & sync your keys behind their servers via passkeys, they will start pushing it to appease law enforcement with the backdoor to your accounts by handing over your keys when asked.
Clever filming trick. I bet he’s right handed.
Congratulations! What a lecture! Amazing, the explanation is sharp and clear. Much is said about what problems FIDO is solving, but I missed some information about what are the weak points?
Thanks for the great feedback! No system is perfect but I do believe this one is far better than what we have been doing previously
@jeffcrume this system has been around for a few decades 😅 maybe it's an implementation thing and if done right it takes off.
Great video. Explained Fido simply enough as If was a small child or a Labrador.
That’s pretty much my target demographic with these videos 😂
@@jeffcrume I'm not sure if it's a joke or an insult. But both are funny. :)
Funny thing, you still need some kind of password to unlock the FIDO process. After all, if you cannot secure your FIDO device/app with a password, then anyone with access to your FIDO device/app can authenticate as you.
I unlock my mobile phone without a password all the time - face recognition
The real difference though is that shared secret is between the human and the device, NOT the human and the server, which in turn means that attacks against it are not remotely scalable.
@@jeffcrume I'm guessing your mobile phone also has a PIN you can type in to unlock it as well. Just in case face recognition fails. Or if it's been awhile since you last typed it in.
Great explanation. Bonus points for seamlessly writing backwards the whole time!
Thanks for the kind complements but I have to admit I’m not that skilled ruclips.net/video/LdnJoT5IWPM/видео.html
My thought is the video was reversed so he did not have to write backwards.
Very nice way of explaining the topic!
So when the device is compromised. They have access to all the user's accounts. 😅😂🤣
Depends on how the compromise occurs. Typically these passkeys are stored in a secure computing chip so that access is not easy. That said, if someone gets complete control (including possession) of your unlocked device, then this would be the same risk as we have today with password managers or (worse) password filled flat files or spreadsheets
It is kinda impractical here in latam because the odds of having your phone stolen are high, that's why lot of people preffer to not to use e-banking apps because the thievers can easily access to your funds, instead a password gives you more control over what can be accessed
Not necessarily … even if your phone is stolen, if you’ve chosen a strong password and/or biometric, they won’t be able to unlock your private key
Excellent clarification, thanks for sharing!
I’m glad you liked it!
This is new to me, Thanks for explaining it in the most simplist way ❤
So glad you liked it!
Interesting although I’ve personally never had problems managing and creating new password. There are lots of password managers to solve these problems you mentioned in the beginning.
You’re probably in the small percentage of the population who actually does this. Most just use the same guessable password on everything
Some password managers like Bitwarden also support storing passkey.
Except those managers get hacked rather frequently. And there's still a boatload of not terribly secure passwords floating around. The best password autogenerated by Safari or Google is still weak sauce compared to actual cryptographic keys.
@@jeffcrume did that really ever cause you a problem? Obviously, I'm not everyone, but since I came up with a simple password when I was a kid in 2012, I've always used it everywhere. I never understood this security craze, like everyone is a millionaire or something. what really pissed me off was the constant emails to the mail because "we didn't recognize your device" As if I gave permission for this kind of security. And in general this FIDO looks like we still have 2 passwords, only they are generated by the server. And if we're talking about a single device, then you could always just save the passwords.
there are also methods you can use to know all of your passwords my only remembering a master password, that you dont need any external assistance with and it can all be stored inside your head.
6:06 You cannot decrypt with public key. I think what you mean to say is that you're just going to equate the encrypted respone with the pre-determined expected response in encrypted form.
Also this mechanism is just going to make things more hectic, keeping a sensitive key on the user's own device is never a good idea.
Encryption and decryption can happen with either the public or private key in asymmetric cryptography
Something encrypted with the private key can only be decrypted with the public key. You *can* decrypt with the public key.
You even went into cryptography basics in that below 10 minute video! That was quite some information (great information) packed into a short video.
Excellent presentation , love the clear window technology make it so much professional well done IBM
"clear window technology" aka glass and pen 🎉
Thanks so much for the kind complements! ruclips.net/video/LdnJoT5IWPM/видео.html
In the MGM ransomware attack, the attacker(s) used a SIM swap or replication of a phone to steal a private key. I assume the same attack can be used against this.
A SIM swap wouldn’t help the attacker in this case because the private key is still stored on the authorized user’s device
@@jeffcrume From what I understand, the attacker had access to the client's email address. But, the attacker didn't have access to the private key, which was on the smartphone. The SIM swap allowed the attacker to spoof the identity of the client. The attacker called customer service, claiming that they no longer had access to the private key. Instructions were sent to make a new private key.
Yep. Either this system leaves you out of luck if your hardware device with the key fails, or it provides a recovery method, which uses traditional passwords or recovery questions and an email address, and thus can be hacked using the usual methods. The phishing site just presents an error when they try to use their hardware device, and ask the user to recover the key using their secret questions.
@@posthocpriorTHANK YOU! I'd assumed it was again down to faking it past a human trying to be helpful.
This is why FIDO isn't the default login method to your bank. Phones are not good candidates for storing private keys in any way shape or form. We don't have a good answer for balancing security against the desire of people to carry their entire net worth around in a shiny device with an Apple on the back.
The property of FIDO that eliminates passwords is identical to using a password manager. So this feels like "marketing" of FIDO to entice users to use it for that reason.
Would it be best practice to generate a unique key pair for every web site used? Otherwise, it leaks cross-domain identity and tracking.
Yes, there are unique passkeys for each site, just as there should be with passwords (although, rarely is this the case since most people don’t even know what a password manager even is)
The passkey has an integrated private key and derivate a private/pub key based on the domain name.
Tell that to a guy that lost 25 Bitcoins because he was stupid and kept seed phrase protected by password manager.
Password managers can be hacked,i never heard of,for example Yubikey to be hacked or bypassed in some way.
In practice probably little difference, but there is a technical difference with a challenge-response protocol and a password. Password manager + random passwords for each site seems plenty good.
@@gblargg What you're missing in that equation is the phishing resistance built into browsers with WebAuthn, that does not exist with password or password+OTP or push authentication systems.
Thanks, this was a really good summary. I'm on board as soon as the major password managers let me export my passkeys.
Excellent, best description seen.
Thanks for saying so!
Thanks Jeff. What if I lose my phone or token. Or it is out of battery. Do I still have possibility to log in key-ing in a password, a recovery pw, or what?
I have the same question!
Exactly similar query
yes but what if I have not any other device, or lost access to them... my digital identity de facto becoming phisical again, but nt me as a person... another device... from a digital twin to a physical twin... ie back to a physical key? philosophising... but net net: I need to enter in my bank account from my brother PC because I have no other way to do that... my pw or passkey is known only by a system which I can't access anymore, or better it cannot recognise me anymore @@jeffcrume thanks anyway for you videos... the best ever seen in 30 years. If you stop by Rome please pay us a visit in our cyber academy
So what if I lost the device that the private keys were stored on? How would the recovery process be since you can’t reset the password because there aren’t any passwords.
Please see the pinned comment
I loved this video. Made it easy and simple to understand.
So glad you liked it!
Impressed how well you write backwards!
I wish … ruclips.net/video/LdnJoT5IWPM/видео.html
Thank you for the FIDO explanation - makes totally sense. What if I'm travelling, get into an internet cafe and want to login into my email without remembering my password - how would this work?
Actually, I would highly advise against this scenario. If you don’t control the system you’re using, you should assume that that everything you type of the keyboard is public information since keystroke logging malware could be installed
You use your device that has Bluetooth and a camera on it to scan a QR code that the internet cafe computer shows to you when you want to use a passkey to log in. In some cases, you might not need a camera. Or you can use a physical security key like a Yubikey or Titan Security Key, as long as they have your passkeys on them.
No password is required when you use those things. You're only required to have your device that has the passkeys stored on it and unlock the device. Or have a device that has a password manager installed that stores the passkeys you need to use to log in, and unlock your password manager. Online password managers like Bitwarden and 1Password can sync passkeys across your devices. Offline password managers like KeePass are safer, but less convenient than their online counterparts.
If you absolutely have to, passkeys support hybrid which means that you can scan a QR code on the computer that doesn’t have a passkey with a phone that does have a passkey. That establishes a Bluetooth connection between the two and allows you to use your phone passkey to log in. But yeah don’t sign into an Internet cafe in general
With your phone authorization 🤡
I like the idea. That looks very convenient and also inconvenient in some situations.
I like it too!😊
Absolutely the best explanation of asymmetric key use that I have ever come across. Thank you!
He can write twisted, I amazed 😮
I wish I could … ruclips.net/video/LdnJoT5IWPM/видео.html
quite nice how they do such videos, write on a glass pane and then during editing flip the video
This is an interesting idea, but doesn't this move the problem to device management? I would like to see more about how (1) the same user could login from multiple devices and (2) how a user could remove a device.
Great video, btw. It was very easy to understand and watch.
Glad you liked it! Sort of, but the device is secured with a biometric so there is still authentication and at a level that far surpasses what most self-chosen passwords would be. Please take a look at the pinned comment at the top regarding your other points
I am happy to see enhanced login or authentication security. Although, I would be glad to be proven incorrect with this assumption, fundamental changes like these maybe challenging for older generation to get accustomed to.
Worrying part is what does one need to do when they lose their device by theft or forgetfulness!
I would argue that this is far easier because there is no password to remember
System has been around for decades. Issue is not public adoption, but lack of cohesive browser API for developers. Also for loosing the device, you can store encrypted private keys on a cloud/ private server if you are comfortable.then you would still need a password, albeit just one
Very good approach of securing the user credentials. In my opinion this approach should apply to the entire web to keep users protected. First of all i think google and microsoft should implenent this approach ASAP.
In fact, both of them already support it today, along with many other web sites
@@jeffcrume and it is called sign in with passkey right?
I think you skipped a step. The server has its own private key and the user has the server's public key. The user shouldn't encrypt with their private key as their public key is...well, public. The user sends the response encrypted with the server's public key.
You’re focusing on a confidentiality use case. This is about authentication. The only thing that needs to be secret is the private key
It isn't he opposite, the hardware key has a private key that is derivated with the domain name. You can register a hardware key with a unlimited amount of website, no need for more memory on the hardware key.
HTTPS isn't covered here, and would have happened first. That's where the server proves who they are by sending their own public key, etc. etc. to get a symmetric session key. Then we need to let the user prove to the server over an already encrypted connection who they are. So... That's why it seems a bit loose -- there's an implied wrapper that he didn't talk about. (edit -- the reason we need to encrypt inside an encrypted connection is in case of my VPN provider or ISP being hacked, they might have set up a secure tunnel already, then set up a different secure tunnel with the user. The FIDO layer breaks this and is covered briefly as "resistant to replay attacks")
Thanks for explaining FIDO, I have a question though, wouldn't someone else be able to log in to the server/service if they use your device? for example, if someone took your phone, and it doesn't have a password, wouldn't they be able to log in to all your accounts?
that's where the MFA like Fingerprint and Face recognition comes into picture
Exactly! A biometric (something you are) combined with something you have (the phone) is likely to be stronger than a user-selected password
There's another question. If your device gets stolen, MFA solves the problem of the thief impersonating you. How do you handle the fact that without your device (which the thief has) you're now locked out of everything?
@@stevekemplin3791when you register, you are asked to register at least 2 key. So you can login with the other key, unenroll the lost one and enroll new key to replace the lost one.
Most platforms sync your passkeys. So if you have access to another device of the same platform then it should sync there. If you lose all your devices, you’ll need to fall back to offline recovery methods if the platform supports it.
Nice concept. Any working demo would have been great
Very well explained thank you 🙏🏻
Please also can you tell me what glass board you used ?
I was also intrigued by the board technique. I assume the video was shot from the other side then mirrored, and he’s not that proficient at writing backwards. The right hand watch would also be a clue that’s the case.
I’m glad you liked it. I actually don’t know where we got the board but there are many out there. Here’s how we make the videos … ruclips.net/video/LdnJoT5IWPM/видео.html
@@Firethorne You're saying that is actually his _left_ hand/arm?! 😮😂
How would this authenticate the user in multiple devices at the same time? Will each device store a unique private key and the server store each public key for each device?
Please see the pinned comment at the top
At step 3. VER:
Technically, PVT can't be used to encrypt and PUB key can't be used to decrypt (only the other way around is feasible)
Instead, PVT key is used to sign and PUB key is used to verify the signature
Both PUB and PVT keys can be used to encrypt or decrypt. Whatever you do with one can only be undone with the other and vice versa
@@jeffcrume Interesting, could you share a reference source that I can refer to?
@@dovantoan3856What do you think "signing" is? Signing is encrypting, its just terminology. The entire point of public key crypto is that you can manipulate data with one key and only the other key can undo the manipulation. Call the manipulation whatever you want, a rose by any other name...
It depends on which public key algorithm is used: RSA (named after its inventors Rivest, Shavir and Adelman) has the feature described in the video. What is encrypted with the private key, can be decrypted with the public key, and this is used for electronic signatures or a challenge-response-authentication-scheme like that of FIDO. What's encrypted with the public key, can be decrypted with the private key, and that is used to send secret messages.
But there is another family of public key algorithms called Diffie-Hellman-Key-Exchange and Digital Signature algorithm (DSA). Most often it is used with so called elliptic curve cryptography, the difference is way too much math to explain here, the technical advantage of EC-based algorithms is that the keys can be very much shorter and thus all calculations very much faster with the same level of security. The EC-variants of the algorithms mentioned above are ECDH (Elliptic Curve Diffie Hellman Key Agreement) and ECDSA, and although the same set of public and private keys is used for both, the math of both algorithms is anything else but symmetric like RSA is. E.g. in ECDH nothing gets encrypted, it is a scheme to generate a key for a symmetric encryption algorithm known at both ends of the communication, without the need to transmit this key or any other secret from one side to the other.
With FIDO2, both algorithm types may be used. However, EC-cryptography has become very popular these days due to various advantages over RSA. So most likely a passkey implementation will use EC-keys and ECDSA to do passkeys.
Sorry but I don't get the idea either. If someone encrypts something with public key only I can decrypt it so this is understandable. On the other hand if I encrypt something with secret key and send it over to someone else and a third guy intercepts and he also has my public key right, becsue this is a public key what is the point of this kind of encryption.
"We're going to lock it down with some sort of biometric or, or...password!" 😂
it seems to be an good step that make it secure and easy for users to interect and use those online tools.
It really is much easier to use than passwords
@@jeffcrume agree sir, and thanks for this comprehensive explaination
Password is still better, if you can't remember it then that's a YOU problem. 2FA made things worse thanks to sim swaps and Biometric data can be easily abused if the owner is dead or being held hostage. Law enforcement can and will use your biometrics against you. Just write down your passwords on invisible ink and store it somewhere physically safe. Also do your best to remember it..
Yep, they keep trying to change something that is perfect .. atleast it's the best we can get.
What if you died on the street and you have bitcoin wallet locked with a password? This way I can have your bitcoins and they are not lost forever
Not being able to remember a hundred or more unique 20-character random strings, is a ME problem???
Good luck with staying safe from phishing then... passwords offer zero protection for that, and its both the most common, and most expensive initial attack vector for breaches.
@@nullx2368"perfect" yea definitely.
What about when you move between devices or on a shared device?
You need a your phone or physical key (like a yubico key) to authenticate
Or losing the phone.
@@jeffcrume I respect your answer. Is that something a grandmother can do? What about a shared device?
@@CreachterZif you share your phone that's your problem
Great video! I'll try to look deep into how can I integrate it to a web app. But its weird that all social media apps and governmental apps also still uses 2fa and password verification systems.
Glad you liked it! I think the transition will take some time but I’m seeing the pace pick up lately
Thank you for the excellent video. Nothing is 100% safe for ever. Its not too far before someone devised a method to access the private keey.
I’m glad you liked it. Yes, there is no such thing as absolute security but this is a dramatic improvement IMHO. We will never eliminate all risk, but if we can lower the risk while making the system more usable, that’s a double win
Password less is terrible for those who look after the elderly who live remotely to those looking after them
When setting things up to use a hardware key, for example, you need the physical device to set up the private keys on, which means you need their hardware key device with you at the time
Why is it these people only ever think of use cases pertaining to their limited view and experience of the world
Hardware keys must have to possibility to create clones. If the key is damaged or lost I want to be able to just continue using a clone instead of losing everything.
If you take care of your grandma's online things. And she should also have access to these services. As an example, access to your bank account, the easiest way would be to use a hardware key for your access (FIDO2 Security Key) and her iPad, smartphone, laptop or computer for your grandma's access. Just like you do with the apartment key.
And if you want to do it for many protégés, then either have one hardware key for everyone or, better yet, a separate key for each one that you attach to the key ring.
Passwords aren't inherently weak they are just totally mismanaged. The sever should never actually know what your plaintext username and password is. They should *always* be encrypted on the user side before being sent to the server. Salting / hashing etc a plaintext password server side is absolutely ridiculous. No username and password should ever be directly associated with any particular account in the database. Which account belongs with which credentials should be computed at authentication time server side only with a local rolling encryption standard.
Because credentials are fully encrypted before being sent to the sever, every website they register to, automatically has unique sets of credentials and the user can reuse even the weakest of passwords and still be able to maintain strong credentials.
The difference is that with public key cryptography you can use just one key for every website without trusting the server to store your credentials securely.
Sure if every website I use has good security practices they will never store my password in plain text. But if any of them ever screw up, that password is exposed, so I'm forced to use a unique password everywhere if I don't want a vulnerability on one server affecting other accounts.
That's just not an issue with public key cryptography, because the private key never gets shared at all.
That's why new credit cards use chips with public key cryptography, which is more secure than swiping the magnetic strip.
I don't think you understood what it was I was saying. You can use the same key and the same username and password at every website.
The browser takes, for example, the URL of the website and utilizes that as a source of entropy to mix the key for that specific site. Every site will see a unique set of credentials and never even know what the plaintext username and password actually are. Even if it's plaintext stored by mistake or otherwise at the server, it's already an encrypted version of your password and username before it even gets there so it just doesn't matter.
Weakest password with strongest hashing algorith still can be guessed with brute force😂
@@telaferrum on the other side of that, its easy to mishandle a private key and lose access permanently. Especially if you are an individual that doesn't have organizational key management. the middle ground would be a key extension protocol that can generate a keypair from a large but memorable password. The generated key is possibly less secure than a high entropy random key but it does not have the downside of being weak to forgetfulness and physical theft.
Yes, you can create backups. But now you have to manage the security of those backups too, and the majority of users would be back in the situation that is effectively 'passwords on a sticky note on my monitor'. A little security and idiot-proof access is often the perfect compromise.
@ra6160
A password that has been encrypted is not even remotely the same as a password that is hashed. A weak hashed password can be brute forced and often cracked with a look-up table. A weak password that is encrypted cannot, unless you're using encryption from 1978 lol.
You’re describing ssh. SSH has been around since 1995… 28 years…
Question is : how do we make websited and services propose such authentication ?
Similar but SSH secures the entire session - FIDO is just focused on authentication
@IBM Technology quick question: What happens when there is a man-in-the-middle situation?
Since the user device is sending out its public key, the MiM will also be able to snif it and when the user is sending the RESP (using the same notations in ur diagram) to the CHAL message, the user device encrypts it with its PVT key which can now be decrypted with the public key the MiM received earlier. The attacker now has UNAME and RESP.
So now all the attacker has to do is instead of phishing you they will brute force the server.
How does FIDO defend against that ?
What do you mean by brute forcing the server?
The public key, uname, and resp are perfectly okay to be known by anyone. The purpose of the challenge and response is for the server to verify that the user *actually* has the private key.
I guess the MitM can also verify that the user is correct, but how does that help them at all? That's not useful information to an attacker.
The point is, nothing that an attacker could ever use maliciously is sent anywhere.
✅ Excellent tutorial video. Gold star award🏅.
Thanks!
sorry for being offtopic, but I am really curious where you got this tool (pen + glassy whiteboard) to present this. much easier to follow the explanation with a tool like this. also much easier to explain it to others. I really like something like this for my "whiteboard". I also so some vmware youtube with same awesome tool.
It's typically called a lightboard. You need to use the specialized hardware and to mirror the video before publishing.
Indeed, see ibm.biz/write-backwards for more.
Props to this guy for writing backwards
Peter Quincy Taggart did a great job explaining this in this video.
One more flaw: If the public key gets stolen from the server by hacking it, anyone could build up a fishing site and pretend he is the server, creating challenges all the way he wants. So to be secure its must also be safeguarded the other way around. That is basically the idea of a 3rd party that handles the authentication, hence Oauth comes to life...
The PUBLIC key is PUBLIC. No one has to steal it. It’s PUBLIC
@@jeffcrumeyea i know it's public, it's like saying your telephone number is public so no one have to steal it 😂. It's still personal data.
What he meant is how the hacker can acquire the public key man😅 because everyone won't give public key voluntarily to some random guy. They have to "steal" it from the original website.
Yes, I prefer passwords over keys based on these systems that seem to fall into being cracked or cybersecurity breach makes it all a vulnerability.
I would say that passwords are far more crackable
A cybersecurity breach wouldn’t matter in this case since all the attacker gets access to are public keys and those are public so it doesn’t matter if the attacker can see them. The main benefit here is unphishability.
@actisenergy
Tell me you didn't understand it, without telling me you didn't understand it.
just get your bar code tattoo already @@jeffcrume
Nice idea jim, problem I see with this is logging into different device, and recovery mechanism if the device that had the key is lost or stolen.
Not a problem at all. Please see the pinned comment at the top …
@@jeffcrume great, I've been considering a startup named FidoVault, aiming to securely store users' private keys for various apps. Additionally, it would provide necessary APIs for apps to enable a seamless Single Sign-On (SSO) experience, similar to "Sign up with Apple" or "Sign up with Google," allowing users to manage multiple apps from a centralized platform. I would love to hear any suggestions from a master like yourself
awesome. that will fix a lot of password vulnerabilities. wow
Using asymmetric cryptography and key can be a good idea, but it is ultimately not solving any problems. You can't remember/carry your private key like you do with your password. What if you want to log into a service from somebody else' device? There should be a mechanism similar to Authy that performs this for you.
The only difference between a password and a private key is that of characters in the string. A private key is huge, a password is typically small. Thats it!
Saying "you won't have to enter the password as the key will handle it for you" is same as having a password autofill feature.
My point is that while asymetric cryptography is good at the needed place, there is a reason why people still use passwords.
Excellent point. And concisely boils down the main concept
> What if you want to log into a service from somebody else' device?
That's a limitation of FIDO, If you want to access your account from a different device, you would need to register each device separately.
>The only difference between a password and a private key is that of characters in the string. A private key is huge, a password is typically small. Thats it!
You're mixing up passwords and pass-keys. They're conceptually different. I'll list down two main points on how they are different
#1. passwords are transmitted over a network, while the private key never leaves your device.
#2. passwords are usually single-factor authentication (unless you're using Authy.. etc), the private key (something you have) is often protected by an additional layer like a PIN or biometric data (something you know or are).
The passkey changes with each login. That’s a big difference over passwords
Assertions in this statement are not true. Cross-device authentication (aka hybrid) can be used to bootstrap a new device from a mobile phone that acts as an authenticator. That was not described in this video. Also WebAuthn offers phishing protection, which is completely unrelated to the entropy of the secrets involved.
Getting rid of passwords by storing them to a file, genius.
That’s not what’s happening. Passwords are replaced by much stronger passkeys which are then protected far better than just putting them in a file
First they are not passwords 🤡
Second they are stored in TPM chip of your device
Thanks for the excellent explanation ... Quick question As a user, What if i want to login from different Laptop(my second laptop) ???
Great explanation! Say i lost my device and shifted to new one then how would i be able to prove my identity and reset those old keys on both client and server?
If you lose your phone, traditional account recovery mechanisms are still possible (answers to “secret” questions, etc.) to generate new passkeys after proving your identity or passkeys can be synced across devices, in some cases
This is how SSH works, isn't? Why we need new name for that?
Similar but not identical. SSH supports passwords, certificates, etc.
marketing ;D
How does this fix the "something you know" problem? This is entirely a "something you have" solution. Proper authn needs both.
There’s not a need for something you know if what you are and have can provide equal (or better) proof
@jeffcrume the problem is that what you are isn't safe from being cloned. E.g. fingerprints, face recognition, iris scanning, etc. There are lots of examples of partners, kids, etc holding an iPhone up to the owner's face to unlock it. That's essentially saying all these other individuals are authorized to their accounts.
FIDO has what is called a UV (user verification) requirement. Authenticators are supposed to require users to authenticate to use them. This is only between the human and the authenticator. Some authenticators (like phones and certain models of hardware security keys) offer local biometric authentication, others use a PIN.
@@sbweeden so they are punting and moving the point of trust. I don't necessarily agree with this security model.
I think that improving security together with usability. We must focus on how best we can allow users to access the system on different devices without comprising security. But this is like we will be trying to decrease accessibility in order to improve on security. In fact, we must focus most on solutions that can protect the system but less dependent user behaviours. You know our users are funny, not security experts. Others don't even know the risks, but we must protect them
Best explanation ever!!
Thanks so much for saying so! 😊
But they kind of already do this...with "trusted devices". For example, Gmail and the like. That's why once you sign in, and don't sign out, your phone or tablet becomes your "password". Once you sign out however, the "no password" nature of the exchange vanishes. For this reason (among others) if there's a "man in the middle attack", say at a public wi-fi hotspot, your password is not compromised after you leave the "man in the middle" and go home to your private Wi-Fi. The "man-in-the-middle" can steal any information that was transmitted at the public wifi but not your password (even if you entered your password there) nor any information once you leave the public wi-fi. The reason is "session" passwords that only last a short time, and the like.
In this case there is no password to steal and the passcode is never sent
@IBM_Technology How do you protect against a Man In The Middle attack during the registration process? Normally we would use TLS, but that is to authenticate the server, not the client. Suppose Alice sends a registration message to the server, what stops Bob from intercepting the message, generating a new Public-Private key pair and sending the key pair as Alice's? What stops Bob from impersonating Alice in the registration process?
@IBMTechnology
Public keys should be signed by a trusted third party. Verifying the digital signature would expose that the MITM is not who you intend to be communicating with. ruclips.net/video/0ctat6RBrFo/видео.htmlsi=ld38U222TeXe5VIX
I had the same concern...
I think the interpretation here is that the public key is the user identity. No public key infrastructure or verification that your name is actually Alice, if your real name is Bob. They correlate your key to your real identity via fingerprinting or third-party channels.
The TLS channel is standard web https connection. Midm is almost impossible because you need a certificate of your domain name registered with a CA . It follow also the registered dns CA authorities or pinned CA...
To impersonate you would need to hack the user's DNS server/connection and be able to register the impersonate domain name with a rogue CA authorities (very unlikely those days)
How does it resolve man in the middle attack? An attacker can intercept the first call and get the public key and then it can generate a public and private key and send its public key to the organization
Please see my response to this same question previously in the comments
So in general: a password manager that would have a unique passkey for each server? Though it does provide added security that the passkey needs to be authorised by the server, so phishing attacks are prevented since the server signs the passkey?
Similar but a password can be reused. A passkey is one time only so less vulnerable over time
I definitely like FIDO. But a good password generator and storage solution is also very nice. But ofcourse there are many added bonuses with the hardware solution. But I will probably not use it for my low-security stuff, simply because it's still a tiny hassle.
A good password generator can be very effective but most people aren’t inclined, nor do they understand how to use tools like this. FIDO can be built in so that it is essentially transparent to the user, something that is hard for password managers to do given the wide variety of web sites
@@jeffcrume Agreed, world would be safer place if everyone knew how to effectively use a password manager but most don't or aren't aware of it. For this reason alone, FIDO holds a lot of potential.
@@jeffcrume yes. it also basically forces the user to generate a "password", because i don't expect the user to be offered the opportunity to make up a password, as a common practice
One thing to note, most asymmetric algos don't work in both directions like you said. Usually you sign something with the private key and validate the data + signature using the public key, and the public key cannot sign anything itself. Same goes for encryption, usually you have one key for encryption, and another for decryption. Otherwise there would be no point in having two distinct keys because as long as someone has one of the two keys they could decrypt the output of both. Luckily as I've mentioned that's not how it works.
I think the private exponent is used for both decryption, and signature generation, and the public exponent is used for both encryption and signature verification. The private key consists ot a modulus, private exponent, and public exponent, and the public key consists of a modulus and public exponent.
It depends on what you’re trying to accomplish. Encrypting with my private key proves it came from me. Encrypting with your public key proves only you can read it.
Ok Great Video, but I want everyone to understand that this guy had to write all characters and words in reversed direction, what a sacrifice! If you reading this bro, I appreciate your effort and you got a huge respect from me 💪 🤟 Thanks!
Or he just mirrored the video
@@dmytrokovtun3561 seeesh you are right :D damn i'm stupid
@@dmytrokovtun3561 Damn, you are right! His Watch on the right and pen in left! ( I'm left handed, and also using watch on a right wrist ). But I've got one more evidence - logo on t-shirt is on the right, usually it's on the left (99.9%).
All the mechanics explained but how do I start using it? What does it take to use this Fido2?
Okay, its actually the solution to passing password online which is not so secure.
But the most problem comes from the local environment, what if they sync the private key or what if they steal your phone. We can't log in on another devices is kinda not comfortable.
It's more secure for sure. If it's implemented i think i will try it.
Please see the pinned comment at the top
@@jeffcrume already read it man, im just listing the possible risks from it 😞
I also loathe passwords and think this is a great step! One concern about how this could alter phishing attempts though. While it would stop blind phishing attempts that we have now, wouldn't it just move the goalpost to gathering as may private / public keys as it can (especially when the majority of people switch to it)? Meaning they can still setup fake websites that query for your private key and store that off for later, and then always be on the lookout for public keys sold from security breaches and the like. Then they can just batch run the gathered private / public keys against each other to see when they find a match, and since they already have it marked where the matches came from, go use that to log in.
Remember that the private key is never sent out so the attacker never sees it
You wouldn't even be able to see your private key, and it would be some really long string of characters, not a short thing to reasonably paste into a website.
@@jeffcrumeyes, but for the system to work during authentication, a website would request the key wouldn't it?
@@theelmagooNothing ever requests your private key. A server would request that you _sign_ something (e.g. a random challenge message) with your private key, which it can verify using your public key. The request is also signed with the server’s private key so your device can verify who’s asking for authentication, and the response is _encrypted_ using the server’s public key so only the originating server can verify your signature.
This is the worst approach of authentication for the general public. All the attacker has to do is steal the device. Also, if the device is stolen there would be no way of authentication left. Basically you can say good by to any sort true anonymity on the internet.
100% correct. I felt like I was the only person here thinking you're making it even worse.
Put all eggs into one basket, and you crack them all at once.
The thief would still need to unlock the device and if you’ve done a good job of choosing a device password and have a good biometric, then you are still safe
FIDO is designed to mitigate the major remotely scalable attacks against todays current authentication systems, which are phishing (both credential phishing and session phishing from MITM), and credential stuffing (due to the problem with re-used passwords). User verification required to unlock the phone helps mitigate device theft (which is not remotely scalable) and synchronized passkeys help mitigate lost device scenarios.
In step 2 you say server encrypts challenge, and on step 3 server decrypts response with same public key. That is not how RSA works. You can do only one thing with a public key: encrypt with public, and decrypt with private or vice versa, but not both. For two side encrypt/decrypt you need two pairs of public/private keys, that is by the way how SSL works.
Signatures are used in FIDO for message level validation, not encryption. I believe Jeff may have been using poetic license to simplify crypto-stuff for not-so-technical viewers into just encryption paradigms, but signatures are what it's really all about.
You missed the part where the device/client uses the private key to decrypt the challenge from the server (which the server encrypted with the corresponding public key), reads the unencrypted challenge then re-encrypts the challenge (or something proving the client read the unencrypted challenge) using the private key and sends that as a response to the server, which the server can use (decrypt with public key) to confirm that the client was able to decrypt/read the challenge.
In particular, you missed the first part of step 3, where the device/client encrypts the challenge response, using the private key.
So what about, for instance, wifi-passwords? You would want to be able to have multiple users authenticate with the same network. How could this be done?
Ever since browsers have included a password manager, I've stopped creating, remembering or caring about passwords altogether, and never had a problem. And if suspect that a password could be compromised, I simply change it, all in a matter of seconds. I don't see how FIDO will make my life better.
The fact that passwords still exist is a problem because they could be compromised (e.g., through a breach on the server side) and then replayed
Regarding phishing, I would not completely agree. MITM attacks are still possible, just harder.
As a cybersecurity professional, I would never say that anything is totally secure. That can’t be the goal or we will only and always fail. The goal has to be reducing risk to an acceptable level and this definitely moves us closer in that direction
@@jeffcrume agree, or barely usable. :)
Just wanted to point out, that users should still not feel safe in regards of phishing; but I'm still looking forward broader adaption. Already for the comfort it (hopefully) brings.
PS: hopefully, because I still hope for better integration in password managers. I personally don't want to rely on key synchronization via Google or Apple; or complete HW binding.
at the end, I just realize that you are writing backwards..impressive
I like it and if you loose your private key just backit up traditionally using a password.
Please see the pinned comment
I see a number of issues for example how would this work across multiple devices. How do I restore all the private keys to my new device? This can be managed. Play will require method of moving private keys between devices. If you think about it when is just substituting private keys add passwords with a little more sophistication
Please see the pinned comment at the top
Yeah, Fido Dido from seven up, now doing asymmetric authentication. Fido Dido your are so cool!
Junior ICT tech here, wanted to ask about a few things, i assume simplifications were made in order for a nicer, lighter flow, but:
the way it was explained it seemed to be really vulnerable for MitM attacks, and the explanation of asymmetric encryption seems just wrong with how public key was said to be used for encryption (i assume normal key exchange is what is actually happening and that was said for simplification, further i also assume anything after the registration is also encrypted), regarding phishing attacks: how can a user identify a server is what it claims it is, instead of a hostile controlled server
This just described RSA which has been around since 1977 and is used by most communication today (SSL, TLS etc.) The only difference is how they are suggesting using it - as a replacement for passowrds. As one commenter says - not sure how all these private keys will be managed ? Is the public key stored locally ? In which case this opens up new security issues.
RSA is the most common asymmetric algorithm but it’s just that - an algorithm. You need a protocol to fill in the blanks on how it will be used such as TLS/SSL, FIDO, etc. for a specific use case.
There is no issue with revealing public keys. That’s why they are called “public”