10 ms·
Clef – stop using passwords
- abc123xyz 13y agoTrusting a mobile app with my passwords? Sure I may as well email all the passwords to the NSA instead
- thatthatis 13y agoSo for this to work, the website has to be on board, the user has to be on board, the user has to have their phone present, the user's phone has to be in working order (camera working, network working), the clef server has to be running correctly, and the software has to be working correctly on [the user's phone, the website's frontend, the website's backend, and the Clef servers]. Current process: click login box, type, tab, type, enter. With clef: click cleff box, find phone, unlock phone, launch clef app, hold in front of screen, wait. All of this to create an "advantage" of not having to remember a password at the cost of probably 15-30 seconds longer login time and a login process with more brittleness, as many steps, and more complicated steps. Is there a big advantage I'm missing, because right now this looks worse in almost every way and dubiously better in only one. I say dubious because I wouldn't trust the system to work, so id still memorize backup passwords. But some people have higher trust and thus would get the benefit. The animation is cool though.
- staticshock 13y ago> the user's phone has to be in working order (camera working, network working) battery not dead...
- johnsocs 13y agoJust about all the widely public 2 factor schemes out there leverage cell phones via SMS or another route, they all require your device to be some battery life.
- pipeep 13y agoI bought a yubikey, but hardly any web services support it.
- mutemule 13y agoActually, any website that supports Google 2FA also happens to support your Yubikey Neo, assuming you have a Neo. Step 1: Install the Yubico Authenticator from the Play Store. Step 2: Install the OATH applet. Linux instructions are at http://forum.yubico.com/viewtopic.php?f=26&t=1159 http://forum.yubico.com/viewtopic.php?f=26&t=1159, but there are OS X instructions kicking around on the forums as well. Step 3: Wherever you would normally use Google Authenticator, use the Yubico Authenticator instead. You now have proper two-factor authentication. EDIT: Wrong link...
- pipeep 13y agoDamn. I bought the standard.
- mutemule 13y agoWell, sit tight. There's a new version of the Neo that supports U2F (https://sites.google.com/site/oauthgoog/gnubby https://sites.google.com/site/oauthgoog/gnubby) coming out Real Soon Now (https://www.yubico.com/products/yubikey-hardware/yubikey-neo/yubikey-neo-u2f/ https://www.yubico.com/products/yubikey-hardware/yubikey-neo...) -- sometime in 2014 is all I've heard.
- deleted 13y ago[deleted]
- subsection1h 13y agoNone of the 2FA services that I use require me to use an actual phone. The phone number that I associate with 2FA services is set up to forward SMS messages to an email account that is dedicated to receiving only SMS messages from 2FA services.
- zyxley 13y agoAlso, if you want to log into the site on your phone, you need a second phone.
- habosa 13y agoPretty sure they have an app to solve that.
- habosa 13y agoThere are a few advantages you're not mentioning: 1) This is two factor authentication. I don't trust any of my really "essential" accounts like GMail or Coinbase without two factor. And all of the problems you mentioned around needing your phone are common to nearly all two-factor auth solutions. 2) More secure password. You won't be susceptible to many brute-force based hacking methods because your password won't be in any rainbow tables or anything like that.
- icebraining 13y agoThis is not two factor authentication, since it eliminates one of the factors (the password). Gmail's doesn't, so that is two factor auth.
- habosa 13y agoClef app has a PIN. And my phone has a lock screen password.
- icebraining 13y agoNo, because you're not authenticating to the service. Think about what would happen if your phone gets owned by some malware that escalates to root. It can simply log the PIN, extract the key and then login as it wishes. That's because the phone is the single factor for the service. Compare that with the auth against, say, Gmail, where even if a malware were to own the Authenticator, it still couldn't login as you, since your password goes directly to the service.
- PakG1 13y agoI finally installed Google Authenticator on my phone yesterday because Digital Ocean utilizes it. It's great. Like RSA stuff, only more convenient. And hopefully given the response of Google's security people to NSA activity, more secure than the RSA stuff. This thing basically looks like a more automated version of Google Authenticator. Cool, but meh, would it really change my life? But maybe it would make a difference for the same market that feels like the iPhone 5s's fingerprint scanner is way more convenient than previous security mechanisms on the iPhone and so can never go back. I dunno.
- ivanca 13y agoPretty much, yeah; this is condemned to fail and they should pivot ASAP.
- deleted 13y ago[deleted]
- huhtenberg 13y agoYes, yes, except this allows you to log in from an untrusted computer.
- thedufer 13y agoHow? An untrusted computer can just steal your session token.
- AndrewKemendo 13y agoThis is wrong though because unless you have the same password for everything (you shouldn't) the process isn't the single serving: click login box, type, tab, type, enter It is moreso: click login box, type one of passwords 1-10, tab, type, enter Which assumes you remember each one. It's an even better use case scenario if you are the guy with only one password for everything.
- chadcf 13y agoI would think something like lastpass is an even better workflow however. 1. click login button 2. there is no step 2
- fsckin 13y ago+1 for LastPass. Saves a bunch of time. They're pretty damn persistent about doing security the right way -- they don't have the key to open your data.
- azinman2 13y agoExcept that's a bandaid over existing solutions. It's hard to imagine in 50 years we'll still require people to remember both a user identifier plus a password. It's a tough problem. Human memories are fallible, yet it's with you always. Passwords can be given to others, which can be convenient in many situations (something bio recognition can't do). Bio markers like fingerprints are left everywhere as CCC has demonstrated, or the markers themselves can change such as with Macular degeneration in eyes. Phones can be stolen or run out of battery, physical key cards lost, and centralized systems like RSA's SecurID hacked. In a lot of ways the banks have it done best, with combining a replaceable physical object (loanable) with a short PIN (sharable and more memorable), and then throwing fraud detection on top of it. It's the last piece that's the best and also the least available for others to do easily. The problem would be better addressed by having a turn-key solution that any company can easily plug into their code to detect fraud attempts on short passwords. Big hole waiting for a startup to fill...
- R_Edward 13y ago
- jbcurtin2 13y agoBeats the heck out of time-based algorithms that generate a code on a fob. Obviously not usable everywhere, but definitely a solid option.
- braum 13y agoOMG this will make moving around the internet and logging into 100's of sites so much easier and faster... oh wait. find app, click app, wait for app to launch, scan screen..., scan screen again...,(damn it!) scan screen again holding further back and making sure it has focus, got it!. whew. that was so cool and easy. I'm so glad my Wordpress admin page has this level of security because what I say is THAT important.
- azinman2 13y agoHardware integration is needed for this and mobile payments to be less frustrating and fast. Apple/Google/Samsung are the ones in control.
- Zikes 13y agoThey keep saying this is 2-factor authentication, but without the first factor (something you know e.g. a password) and going straight to the second factor (something you have e.g. your smartphone) they actually only provide a single factor for authentication. This is of course less secure than true 2-factor authentication, and the web site is misleading in its wording.
- famousactress 13y agoTo be fair if your phone is locked with a pin then we're still at least roughly in "something you have and something you know" territory.
- stcredzero 13y agoVery roughly. When you put in your phone lock pin, you are not authenticating with the website. So roughly, it's not.
- giovannibajo1 13y agoI dont see how that matters. You still need a password + one file (on the phone). SSH keys with passphrase are two factors as well in my book. In fact, I would say that not having to transmit the weakest part (the mnemonic password/pin) over the wire is a plus.
- stcredzero 13y agoI dont see how that matters. Please tell that to anyone thinking of hiring you for security.
- gphil 13y ago> They keep saying this is 2-factor authentication, but without the first factor (something you know e.g. a password) I always wonder about this even when there is a password. For most services, a phone compromise would be a total compromise. I rarely get prompted for a password on my phone (nor do I enjoy typing one when I'm trying to do something quickly.)
- ngpio 13y agoI'm glad there's movement in this space. It's desperately needed. Password managers are great but difficult to extend to all use-cases. When a generated password cannot be easily copy-pasted, the whole system feels unwieldy. But Clef doesn't seem to solve anything in that respect. It solves some of the same problems that password managers do but with extra environmental requirements. I can see the Clef mechanism being useful for 2-factor authentification. But I'm unenthused with (and wary of) its current instantiation as a login skeleton key. If I were Clef, I'd set my sights lower and rebrand as a drop-in 2-factor auth system to be optionally enabled by users. > Clef puts military grade cryptography in the hands of every user This kind of line is deceptive for 99% of end-users and turns off the 1% who might be helpful as developers.
- serverascode 13y agoWhere do they say military grade? That's always a bit of a red flag for me.
- jessepollak 13y agoThis is actually something we thought we removed everywhere. I just grep'd our repo, found one lingering instance, and committed it out (will deploy when the traffic goes down). We understand it's deceptive and recognize the need to communicate to our users why Clef is more secure than usernames and passwords in a straightforward way.
- tscherno 13y agoHere: https://getclef.com/developer/ https://getclef.com/developer/ Also: https://www.schneier.com/crypto-gram-9902.html#snakeoil https://www.schneier.com/crypto-gram-9902.html#snakeoil
- jimktrains2 13y agoWhy not just have browser support for SRP as a standard type of form request or TLS-SRP? It's fairly well known crypto and doesn't require a 3rd party service to be active or access to a smart phone with an active network connection.
- jamiesonbecker 13y agoGood thought. I believe SRP is patent-encumbered.
- gcommer 13y agoActually, it is just the opposite. According to wikipedia, SRP was carefully designed to avoid any current patents, and according to this stanford page[1], it is available commercially and non-commercially under a royalty-free license, along with a BSD-ish-licensed Open Source implementation. [1] http://srp.stanford.edu/whatisit.html http://srp.stanford.edu/whatisit.html
- ianburrell 13y agoSRP doesn't solve the problem with having to remember (or store) good unique passwords for each site. It does help with the authenticating password over insecure connection but SSL solves that for most sites. It doesn't solve the problem of securely storing passwords; the value that is stored can be brute forced to get password and is equivalent to cleartext password for any SRP using site.
- jimktrains2 13y ago> It does help with the authenticating password over insecure connection I'm not sure you understand what SRP is; it's built to be used over insecure connections. > It doesn't solve the problem of securely storing passwords; the value that is stored can be brute forced to get password and is equivalent to cleartext password for any SRP using site. I don't think you understand what SRP is; if you could do this, then public key crypto has a much larger problem then passwords and you should be worried about TLS as well.
- 13y ago
- cell303 13y agoSorry for the deliberately stupid question but: What if I need to login somewhere on my phone?
- gcommer 13y agoThe image that you're supposed to scan will also be a link with some custom procol (like clef://...), which then gets handled by the Clef app.
- eatcookies 13y agoWould be better if you cut out the centralised authority, take a look at SQRL https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm
- supermatou 13y agoSo, basically, I should replace something that exists inside my head, in an immaterial form, with something physical that can be easily stolen?!
- johnsocs 13y agoYou could still say this is 2-factor, I know my phone PIN, and I have my phone. It's interesting, yet not for me. I'd rather keep with the SMS PIN's as part of my two-factor auth, no third party app required, no lost private keys. Most people who jump on the 2-factor band-wagon care more about security then speedy access. They are willing to carry an extra device ( smartphone, smart card, USB key, etc... )
- higherpurpose 13y agoSeems a little similar to Steve Gibson's SQRL, I think: https://www.youtube.com/watch?v=ZrQboo3pA10 https://www.youtube.com/watch?v=ZrQboo3pA10 http://sqrl.pl/guide/ http://sqrl.pl/guide/ https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm He said in his recent Security Now podcast that he had some breakthroughs in terms of how SQRL will work, so it will probably change quite a bit from how it's presented at those two links. He also said his solution is better than what the FIDO Alliance is trying to achieve, but we'll see when it's ready if true (it does sound like the FIDO Alliance has created a few adoption problems for themselves with the licensing and whatnot, though).
- mixmastamyk 13y agoThat one doesn't require a smartphone, I believe.
- dublinben 13y agoThis immediately struck me as a ripoff of SQRL. I don't think there are any meaningful improvements in the linked solution.
- gcommer 13y agoActually, Clef was already developed and launched before SQRL was even announced. SQRL does, however, have many benefits over Clef, though the typical user interaction is similar.
- sidmitra 13y agoSo one use case, where any phone based solutions are a bit off is: when you're travelling. 1. Phone in roaming and no network 2. Battery dying out. It locks you out of using a bunch of services. I had a really bad time when my flight to NYC got redirected to Tashkent and was stuck for 2 days. I couldn't logon to any services. My phone wasn't working, so i did not receive sms notifications i had setup. GMail(and FB and a bunch of others) all thought my account was being hacked and wanted me to verify via my phone or email. So i was stuck in a foreign country, with phone roaming not working, and no way to contact and let people know that where i was. So i've definitely stopped using any SMS phone verification, i'm still hesitant to use Google Authenticator(although i've shifted most of the accounts to it), because my battery tends to die at odd times while traveling.
- IgorPartola 13y agoI am glad that people are exploring this space, but Clef is not the solution, IMHO. LastPass currently fulfills similar requirements for me and actually speeds up logging into the site. Is it perfect? Absolutely not. But the UI works pretty well. I'd like to see it improved by starting to support public/private keys. The idea that I can log into a site using my private key means that when I simply get one <input type="identity"> and then the browser or a plugin like LastPass provides the UI to fill it in. This would actually be much faster than passwords: you see the input, select an identity from a dropdown or autocomplete you'd like to use, and click "Go".
- cauliturtle 13y agoI am so scared moving all my "right" to my phone. If my phone is stolen, that guy can browser my visiting sites history, and then try to use clef to login, payment...
- normloman 13y agoDrat, he's using clef! Oh well. Hit him over the head with a cro-bar and take his phone.
- negamax 13y agoThat's really cynical. This is as good as saying, put someone under sedatives to get them to reveal their password.
- dvanduzer 13y agoSecurity professionals have always distinguished three major potential factors for authentication: - something you know - something you have - something you are (e.g. fingerprint / retina scans) Part of the reason passwords have stuck around so long is that accurate and convenient enough biomarker device have been prohibitively expensive, and physical artifacts can be lost or stolen. You can't put someone under sedatives to get them to reveal their password. To attack a password* you must coerce or trick a human brain into revealing it. *Assuming various diceware-style caveats. Also, writing the password down and putting it anywhere other than a safety deposit box puts it back in the "something you have" category.
- homakov 13y agoWhat about MITM, if I show image of client 1 on client 2?
- drdaeman 13y agoAlso XSRF with QR code meant to log in to site 1 shown to client on site 2.
- gcommer 13y agoI don't know if clef does this, but for SQRL (similar, but uses QR codes, is open source, and doesn't rely on a 3rd party), it relies on the fact that the website URL will be embedded in the QR code (along with a signature) and that the app will show that URL to the user for them to confirm. This isn't strictly stronger than standard password MITM (phishing), because unattentive uesrs could still just click through without checking the URL or the https status. IMO it is still an improvement because it makes that step explicit, and gives us a chance to put some nicer UI and programmatic checks around it (warning about weird unicode tricks, high similarity to previously used domain names, ...). Also, both Clef and SQRL use public-private key authentication, so if a bad guy does successfully MITM someone, they only get one session to do bad stuff as opposed to knowing the password and being able to re-authenticate wherever. Obviously this is pretty poor security (it only takes one login to empty someone's bank account...) but for some applications it might be significant - notably for websites require you to re-authenticate to take destructive action.
- cliveowen 13y agoAnything that requires the user to pull out the smartphone and launch an app to authenticate is bound to fail. There's no way around it.
- staffordrj 13y ago> There's no way around it. That's the idea.
- facorreia 13y agoInteresting, but I couldn't find the answers to some questions on the site: 1. How much does it cost for the website / web application owner? 2. How much does it cost for the end user? 3. If nothing for either, how does Clef make money out of this?
- hundchenkatze 13y agoFor 1. Go here: https://getclef.com/developer/ https://getclef.com/developer/ it's in the middle of the page "Completely Free" For 2. The App was free and I was able to use it free. For 3. No idea :)
- LanceH 13y agoHow do you log in from the web page on your phone?
- aaroneous 13y agoIt's good to see advancement on the ux side of 2fa. Many of the other players in this space provide such a cognitive burden that scares average users back to passwords. I'm excited to see where this one goes.
- smsm42 13y agoDo I understand correctly that this is just plain old client certificates with nice wavy picture on top of it?
- 1morewebdev 13y agoWasn't there news recently about popular games picking up stuff from the phone that they are not supposed to? If I keep my passwords / certs on my phone, anything that hacks my phone gets access to those, no?
- mcmillion 13y agoYeah, I'll just type my password, thanks.
- ricards 13y agoVery similar app only with QR codes - http://capturein.com/ http://capturein.com/