SecureLogin Authentication Protocol 1.0
medium.com
medium.com
Today I use auth0 configured as a passwordless solution, i.e. email code + login, or use Google OAuth, etc. You can see it working on sites like https://www.lfgss.com/
I would consider another solution, but I'm not sure that this is it.
The information is sparse, as a site-owner it hasn't really sold me on:
1. how this works
2. that the first login friction for the user is low/effortless
As I understand it, this is not a "password manager", but more along the idea of a "login manager" that you install locally.
And, if you do not wish to install something locally then there is a browser bit which I think is in JS and this is "less secure" and "slower"... but this in itself puts me off the whole idea because I think the browser bit is what most people will use, and that security is fairly boolean so "less secure" probably equals "not secure". If this is just a communication of risks, then those are not being communicated.
But I'm curious enough to want to know more, so I googled, found his Twitter, looked through and saw others asking similar things to which the author response amounts to "read the code".
It feels like a poor sell, because whatever this is may well be the kind of thing I'm looking for. But I just do not know.
Changing authentication is such a big thing that I can't see me moving from passwordless auth0 unless the communication is super effective... not just for me as a site owner, but also for end users who will wonder what it is being asked of them and whether to trust it.
So if you are a developer, your best bet is "How it works?" here: https://github.com/sakurity/securelogin
If you don't speak Ruby, hit me up I will dedicate all my time to help you.. and even get free audit as early adopter. FYI we conducted security audit for Auth0 (https://sakurity.com/)
Actually by using auth0 you rely not on one central authority, but on two: auth0 and google/microsoft oauth. If _either_ of them is compromised, your users accounts are too. If that worries you, try SL:
With SecureLogin you only rely on the local app user installs. First login friction? Not great, but is getting better, I'm giving it daily to normal users and it improves.
> If this is just a communication of risks, then those are not being communicated
Correct, that message is not very informative. I think it will be removed.
https://github.com/sakurity/securelogin/commit/975332ae0b0e2...
Literally just "1". Tells me nothing about what's happening in this change, and from the diff, it looks like quite a lot ("118 changed files with 283 additions and 179 deletions").
Besides, everyone writes shitty messages every now and then. Don't judge their code by their use of a VCS. It's like judging a person's articles by their notes. I've got terrible handwriting.
After reading the guidelines for the Linux kernel I've always given full and proper commit descriptions for effectively all of my commits (with exceptions for projects which don't matter, and such messages aren't going to be read by anyone -- including me). I really wish more people did this, because it makes bisecting, backporting and otherwise spelunking projects much easier.
To put it in your analogy, it wouldn't be fair to judge a programmer by their handwriting. But it might be fair to judge a secretary by their handwriting (you'd be annoyed if your secretary didn't write down important details, or wrote them in a way that nobody could read them).
Except notes rarely are intended to be public and used for communication with other developers. While I agree that bad commit messages every now and then are not a big deal - that is not what the original commenter was referring to. Of the 23 commit messages, 8 of them are just "1".
The only meaningful commit message was from a 3rd party PR that was merged. For security-related code, "hygienic" coding practices, including quality commit messages, are - at least in my eyes - important.
Not a telecom provider leaking your SMS codes,
not email provider resetting your passwords, not
Facebook Connect/Google OAuth issuing your access_token
to someone else.
This. Not necessarily auth0, but passwordless auth.
Humans forget passwords routinely. It's at odds with realistic expectations of the human brain.
If email is compromised, so is the password reset mechanism.
Tacking on FIDO U2F and one can have reasonable expectations of identity.
No password DB exposure, no password guessing exposure, no remembering passwords so better experience and less support costs.
If we didn't have online password resets then we wouldn't have to worry about the e-mail account being the weak-point. I would argue that no service that offers an online password reset mechanism deserves it.
If I mess-up my bank login, I have to go to a branch to initiate the re-authentication process. Password in the post in secure-mail envelopes, things like that.
If I screw-up my Amazon login - well, that should really be too bad, end of story. Just create a new account. There's too much risk in having an online reset mechanism that could enable someone else to use my cards for purchases.
There are lots and lots of serverless password managers, and their uptake is even lower than that of real password managers.
Is the cleverness here that this one is exploiting modern browser API to quietly embed the whole thing in localStorage so that users don't have to install it?
But let's take it real and look at password reuse problem. Can you admit that password managers and/or 2fa are not what we need and where we should stop for securing users?
We always needed an __enforceable__ protocol that has clear flow for the user. Button. Download, Generate profile, use to login anywhere.
I thought it was made clear that it has nothing to do with password managers. It's an authentication protocol that's 1) decentralized 2) extremely usable 3) scalable. That's all it is.
It's like https://getclef.com/ or SQRL or Mozilla Persona, but not exactly a manager.
By being a protocol it can be _legitimately_ deterministic (you know why deterministic managers aren't great, Tony Arcieri wrote a good post)
By being deterministic it can be absolutely free and scalable
By being scalable and free I hope it has a chance for being popular (no vendor lock-in).
No real innovation, definitely, but in little details it's a good balance of existing things.
Some questions/comments:
1. The github would be clearer (to me, anyway) if the protocol were written out in prose rather than in code. That may account for the following question:
2. It's not clear to me how the origin of the auth request is validated on the auth GET. I.e. how does the "relying party" (so to speak) validate that the SecureLogin client is following an auth link that wasn't MITM'ed by a phishing page?
3. I actually think the URI-scheme/browser-integration is a clever idea, and the UX flow seems fairly nice to me.
4. I think you're sort of kidding yourself if you say that lost-password recovery is not a big deal for big providers like Google and Facebook. For smaller providers, falling back to email verification is fine--or maybe doing nothing. Big providers offer all kinds of verification--email, SMS, domain-ownership, credit card--and a human customer support path. That doesn't change with TOTP or U2F, and wouldn't change here. Not a dealbreaker, really, but it's worth noting this weakness (lost-auth recovery) is probably here for the foreseeable future.
5. Having to enter your master password sometimes is a UX feature, not a bug--it teaches users to remember the master password. Just something to keep in mind on the client apps.
2. I'm not sure if that's what you meant but I just realized pretty bad bug in current callback=ping flow. When malicions page opens my.app for me and second later opens securelogin://#state=THEIRSTATE... so my sltoken will be matched with their state and they will log into my account. That requires good timing so not super severe but definitely will be fixed: if someone opens the app twice in a raw it will notify the user. Thanks
3. There's pretty much no alternatives working cross platform.
4. Which paragraph are you refering too? When I try to reset my Gmail password it boils down to: "dude you forgot your password, no backup email... we cant help here".
Checking now, I cannot setup a gmail account without a phone number or backup email. I can also reset my password as long as I have access to my phone which is currently logged in.
> In the end of any authentication scheme there will be a password that you just cannot forget. In SecureLogin we removed unnecessary levels of "backups" and "recovery codes", our scheme boils down to one master password, not to master password and backup file/paper/SIM card/email account etc.
I don't think a backup is "unnecessary". It lowers the chance of being completely locked out.
What happens if I forget my master password? Does it mean I can never log into the sights using the same account ever again?
> Does it mean I can never log into the sights using the same account ever again?
It's up to the websites, they could use your email for reset + lots of personal info you have about account activity.
Have Google changed something? I had to go through account recovery a while back on a gmail account (with no backup email/number set).
They asked a bunch of questions to try and prove whether I was actually familiar with the account (when did you create the account, provide an address you've emailed more than once in the last month etc). It was a PITA, but I eventually regained access
4: I don't think that's true. Gmail has a heuristic recovery based on knowledge tests. It's _easier_ if you have a backup email or SMS, but not required in all cases.
As an aside, another downside of this approach is that it requires server-side state. Not a huge deal in most cases, but it can present a scalability limit versus cookie-only (signature-based) auth schemes. If the client were able to relay cookies or redirects back to the browser--which seems like it should be possible by simply opening a redirect in the https:// scheme--you could avoid that, no?
4. Have you tried? Because they seem to ask too hard questions like exact date your account was created.
> downside of this approach is that it requires server-side state
Using key-value for delivering signed token to first request? there's callback=direct that opens the link instead of pinging it, but it's a huge pain to figure out which browser you used if not the default one.
4. Yeah. It's a pain in the ass, but they do offer lost-password fallback. Anyway, I wasn't trying to belabor the point; just noting that big sites will probably always offer some lost-password recovery.
> there's callback=direct that opens the link instead of pinging it, but it's a huge pain to figure out which browser you used if not the default one.
Where can I read docs on the different behavior between callback=ping and callback=direct? I know I could read the source code, but I do enough of that in the office. ;)
While I see the potential, I understand that this is an initial implementation, so it has UX issues:
1. First and foremost, the user has to download an app in order to sign into your service. That's a huge ask. Service providers will be hesitant to implement this, since this will mean losing customers. The implementation has to be really polished for this to gain traction, IMO. Without getting initial traction, it's less likely that this can be implemented natively in browsers/OS, where this technology makes more sense and can have better UX. Kind of a catch 22.
2. Related to 1: A 50+MB Electron app is definitely not a casual download. It has to be as lightweight and OS-native as possible. For most likely use case (web app authentication), did you consider using browser extension that would store the data locally? Might be a good alternative to a downloadable app at least for that common use case.
3. When signing in, it asks if one has the app installed. I don't want to be asked. If the app is not there, I want to have it installed in one click, and then have the auth retried. And visiting a separate https://securelogin.pw/ site for downloads is not the best option as well. This bootstrapping process is very important. Again, a browser extension might help with this, since it can communicate with the page and make itself discoverable.
4. As I understand, Cobased is your reference demo app. As such, it needs more polishing/explanation (read: some narrative in addition to the UI).
---
And a non UX-related question: nowadays people not only value security, but anonymity as well. Does SecureLogin have to pass profile email address back to the app? Can the protocol work in the way that simply uniquely identifies the user for the target service via providing some service-unique token but not disclosing an email address? In other words, the protocol might benefit from the fact that no one can link account on service A to the account on service B.
I don't know what protocol is used, and I've never tried it, because it's not part of the single-user Duo Mobile app.
But this always struck me as a much more user-friendly way of doing 2FA than the Google Authenticator style that generates numbers that you then have to manually enter.
But apart from arguably good iOS app UI, it takes the whole IT department to enable Duo 2FA and educate employees on how to enable and use it on their personal accounts, and that's what I don't like about Duo and other solutions. Also, this is just a second step of the two-factor auth, which means the first step (usually plain old username/password auth) is still there.
In my ideal world, I'd prefer something that worked out of the box (with very easy bootstrapping process). I believe SecureLogin, as a concept, has potential here, and if implemented right, might lead to some standardization and implementation of more transparent 1FA/2FA flows.
Interactive Brokers have had something like this for a couple of years.
1. I myself hate native apps, but the catch is web apps are 100% depended on the servers behind them. So I would be responsible for JS I serve any single request. Otherwise, Web version is fine.
Lots of catch 22. I would definitely through $10k+ on a polished UX + native app, if someone with large userbase can commit to using it. I already gave this project a TON of my time.
2. I hate that 50MB size of electron apps too. Browser extension does have same problem as a website though. That's neither more secure nor more fast derivation, so that idea was dropped first.
3. Actually there's amazing self-discovery iframe - https://securelogin.pw/s when in iframe it will parent.postMessage if you have a native app. But Safari does not support 3rd party iframes...
You think showing app links on the same screen is better? Good idea
4. Will improve the demo app
That's what profiles are for. If you want another identity: create another profile. It is possible to keep unlinked accounts under the same SecureLogin profile, BUT we end up with all websites asking for your E-Mail (like they need it for some reason) so that's why it is sent by default.
Real privacy is hard, it's not just different email. It's different browsing context and sometimes even VM. That's why I do not pursue paranoid level privacy, and just offer Profiles.
Happy to hear more.
I believe that it'd better be explicit (like in OAuth, where the web service asks for a permission to access your email) and optional (defaulting to not asking for email).
Note that services usually don't need emails (at least not right away). They should also continue working just fine if the user decides not to provide their email initially — the service may ask for user's email at a later step. I also see that the similar concept might be used to ask people for or other sensitive data, like delivery/billing address and payment info; this way I as a service developer don't have to store anything on the web service at all except for the unique user token, and the user would be able to provide this information with a single click as well — same as in your demo app where the user confirms a transaction.
> Browser extension does have same problem as a website though. That's neither more secure nor more fast derivation, so that idea was dropped first.
I'd probably disagree here. Installing an extension is much faster/easier than a native app; it can store data in localStorage (so no centralized service is needed), it can solve your Safari-related discoverability issues, and it can provide a really nice UX for web-based service authentication with no context switching between apps. I'm not a security expert, but a browser extension storing your data locally should — theoretically — be as secure as a native app. Am I missing something here?
Would love to continue the discussion offline. Is it ok to email you?
I can continue about extensions there
Then once it gains sufficient adoption, sites would be able to slowly start phasing out the use of passwords by making the use of SecureLogin mandatory.
"Classic passwords/2FA are poorly designed, hard to backup and inconvenient to use."
That's insulting. Stop that. Want to state that as your personal experience, fine. You are really too young to declare that with any authority. Quote a crypto legend or take that out. You will alienate a huge pile of developers you claim to be courting.
"SecureLogin's #1 goal is to fix password reuse"
That by itself is easy to solve. Generate the password for the user.
"Usability: existing onboarding process is a disaster for conversion"
Requiring a native app is a disaster.
"Central authority"
You're confusing out of band authentication with centralization.
"no iOS support"
SecureLogin can't guarantee their native app won't be pulled from Apple's app store.
"open source"
LICENSE.txt not found.
Not if this is a reference implementation of a protocol that ends up built into operating systems.
If the point is to be a reference implementation, though, I'd rather it was a reference implementation of, say, better OS/browser handling, syncing, and UI for TLS client certificates.
If everyone is already using something, then the existing implementations are probably already near-optimal, so it's hard to do better and easy to do worse. You can expend a great deal of effort in such a space and—almost all of the time—all that effort will be for naught, because your solution will end up different but not necessarily strictly better for any particular use-case.
On the other hand, if everyone agrees that a design is great in theory—but nobody is using it—then that suggests that all current implementations are crap—and so that's a great niche to innovate in. It's hard to do worse, and very easy to do better—and "doing better" is likely to turn "the thing nobody uses" into "the thing at least some people use", with your name stamped on the side in the process.
Except the one time I've seen it in the wild, the implementation/UX was surprisingly good. Turns out Firefox can generate a cert entirely client-side and install it via Javascript. Chrome draws from whatever cert storage the underlying OS offers, so it should be as simple as saving the cert file to disk and opening it.
Mobile might pose a problem. Would have to try it out.
Long story short entire concept of client certs is not as usable in terms of backups/enrollment as I want to, no matter how well dialogs are implemented.
That's what I was referring to when I said "all current implementations are crap." A better implementation would change that (by e.g. having client certs sync in browser-sync like cookies do; and sync in the OS between devices like macOS keychains do.)
Sorry never tested on that platform. But web app must be working, just press Cancel if app is not installed. Native app is not required but recommended.
It's deterministic - enter same password, get same profile. No sync needed.
> That's insulting. Stop that
Wait, you seriously feel all these "your password must have x, y and z, confirm it, scan QR, enter digits" as convenient? Don't listen to me: watch any password manager promo video. Everyone in the world knows auth is broken.
>That by itself is easy to solve. Generate the password for the user.
Yes, but there is goal #2 and others.
>Requiring a native app is a disaster.
Necessary evil? All password managers are native apps too.
>You're confusing out of band authentication with centralization.
Verification through central authority API or gateway is also out-of-band, i.e. user<->authority<->server. These terms are not mutually exclusive.
>"SecureLogin can't guarantee their native app won't be pulled from Apple's app store."
There's no reason for this to happen, it's not an uber :) In App Store soon.
>LICENSE.txt not found.
Will be fixed. Which one is your favorite?
I want to try your thing, so I press cancel? That doesn't seem terribly intuitive. I thought your main selling point was usability.
>Everyone in the world knows auth is broken.
Auth is broken when you have a HIPAA breach. Try explaining how convenience fits in there to someone deciding if you've been negligent. It can mean the difference between prison and no prison.
>Necessary evil?
The current onboard process hurts conversion, so that's a disaster. Instead, we ask users to download an app, which they don't[1], it hurts conversion, and that's a necessary evil. A rose by any other name...
>There's no reason for this to happen
Maybe not today. Apple has the power to put any developer on their platform out of business, overnight. Apple could decide to amend their "Application may not download or install executable code" clause to include JS apps that it didn't before. They've wiped out huge swathes of apps in the past. If auth is down, the app/service is down. I'd hate to have a large portion of my customer base wiped out permanently by a policy change at Apple.
[1] https://www.recode.net/2016/6/8/11883518/app-boom-over-snapc...
To be precise that depends on client implementation, we will use a popup that doesn't even redirect anywhere.
[1] - exactly my thoughts. Web is a good way to go, but the apps are what many security-minded folks require, so it's both.
> Apple could decide to amend their "Application may not download or install executable code" clause to include JS apps that it didn't before
I kind of support that anti Unrollme policy. They could outlaw all Cordova apps, but that would be a disaster. It makes me think to make going back to web app easier, will look for a way.
It's definitely not an easy problem. I hope I haven't come off as too harsh. Client certificates would be great. I think you write off the value of hardware tokens too quickly, but by all means, look at other ways. Auth is one of the first things any of us have to do when putting together a service. This is something a lot of us have studied for a long time. Welcome to the party :)
Requiring certain character classes is not mandatory for a password.
The 2FA initial setup could be improved slightly, but it's not that much worse than your entire login flow, and it has actual security benefits.
> Everyone in the world knows auth is broken.
Well apparently not.
> There's no reason for this to happen
There's no reason for you to dismiss valid statements about external risks as "There's no reason for this to happen", and yet that happened, didn't it?
> Which one is your favorite?
I'm sorry, are you analysing the best open source license to use for your code, or taking a lunch order?
The README addresses a concern about "Master password is single point of failure in this system", but it talks about the case of a user forgetting it, not accidentally disclosing it.
(To be clear, this complaint applies to all schemes that rely on passwords derived from a master password.)
I've had people paste their passwords to me a couple of times over the years too.
Instead use something on the homerow like "jkl" to end every password. Then the input field just accepts whenever /.*jkl/ matches.
This mostly solves the "wrong focus" problem because hitting Enter is no longer part of the muscle memory. Of course you could still enter it into a shared Google doc or something else that discloses without Enter, so it's only a partial solution.
A two-part password (no, not two factor) where
part 1 is stored by the browser and recommended to be written down or otherwise recoverable
part 2 is remembered by the user from day to day.
Now if the user types the password into the wrong field or the keyboard is bugged they should still be fairly safe as long as part 1 is a good password on its own.
Or maybe I didn't understand the original idea.
So they could sign up another device by just opening a safe and finding it or sit down with book x and reconstruct it.
So slightly harder but still very much doable.
Say, Attacker knows User is a member of Site X, but Site X fails to implement checks and/or rate limits properly. Attacker brute forces master password by spamming the login endpoints.
Extrapolating: a database leak of any site means the attacked can locally brute force master passwords of all users?
Currently, such a leak means a subset of users who reuse passwords are in trouble. Widespread deployment of this kind of scheme would take away choice, and put everyone in trouble. (Unless you start using different master passwords to create bubbles, which means we're back to square one.)
It's like saying about credit cards - " but what if I randomly read the card number and pin out loud". I'm sure it could happen but it seems silly to bother criticising.
Except that's a reasonable scenario with an easy answer: If you compromise your credit card information, you call the issuer and you cancel the card.
The great thing was that, even though that was my most sensitive password (the only that unlocks my desktop and encrypted folders), it didn't matter because all I had to do was immediately change the password in the only two places it was used.
I will never trust generation of site-specific passwords from a single master password. Too many things could go wrong. There could be a bug in the derivation algorithm, crypto might become brute-forcable, etc.
This criticism does apply to all methods that use one master password to derive all other passwords. They necessarily have the master password as a single breaking point.
TLDR. Your technical writing is bad and it is putting lots of people off.
1. Learn to write arguments properly. Your claims are outright wrong and ridiculous. You provided no strong evidence thus just reading your blog post put off lots of people.
Examples:
"It is production-ready to be used by four Billion people by tomorrow morning" -> no, it is not. You are underestimating the time complexity of integrating your project with existing apps. Show me how many people are using SecureLogin 24 hours from now? By the way "tomorrow morning" without an exact date is vague.
"terrible usability. First one offers you to write down backup codes on a paper (which I never did)" -> use your personal anecdote as an evidence is not strong unless you show me statistics of how many people who wrote down backup code (I did).
2. Learn to write protocol documentation properly. At least include a figure of the protocol flow and pointer to your code location. No matter how interesting is your concept, many people will be put off digging through your github project to understand the protocol. Not everyone is familiar with Javascript.
> Unfortunately OWASP is out of touch with reality. First Top10 was released in 2003 and back then the web was a mess. CSRF? Everywhere. XSS? Give me a minute. SQL injection? Just try another parameter.
This is idealistic to say the least. Those things are still very much issues, and sadly are likely to continue to be for some time.
> You are underestimating the time complexity of integrating your project with existing apps
This is not a relevant blocker for being production-ready: websites _can_ read the docs and use it. The server could go down (valid blocker), but not that.
Edit: Yeah, with the crucical difference that you don't need to worry about the server's user database getting leaked along with your password.
> Cryptographic key never leaves your device
Also, have you reviewed Web Authentication specification? It sounds very similar.
What about offline generation of thousands/millions of combinations, for later attempts against SeucreLogin enabled sites.
The password is something the user has to remember, so it's still not going to be particularly strong for the vast majority of people.
Definitely not millions. It takes 20 seconds on a modern chip, it's memory hard scrypt so yeah, even few thousands are too expensive to crack.
I applaud this initiative since it lists exactly the reasons why we started Authentiq: Decentralization, usability, privacy, safety for end users (which is very different from merely offering security features that most people don't use).
Authentiq is similar in goals and architecture, yet with a more comprehensive feature set, since we aim to support existing standards (like OIDC) as the integration point for developers, and offer a more complete mobile identity to end users so that the site owner doesn't need to store those details either.
That said, I'm very keen to see if we can add support for the OP's authentication protocol soon. Check us out here if interested: https://www.authentiq.com/
It doesn't sound plausible, it only works without a middlemen.
A third, replacing our current auth flow with SecureLogin indeed isn't likely to work for reasons you mention.
>"Currently the only way to have safe authentication is to either enable TOTP (like Google Authenticator) or using a USB stick like U2F.
Both you need to do manually so practically nobody is doing that. They both provide terrible usability. First one offers you to write down backup codes on a paper (which I never did), second one is barely supported by anyone."
Aren't many people using Google Authenticator/Yubico/Push Duo versions of TOTP for github logins, gmail and bastion hosts? I thought this was becoming increasingly more common. At least its been pretty standard in the shops I have worked at in the last few years.
Also Github, DropBox, Fastmail, Gmail, Wordpress, Chrome, GitLab and BitBucket all have support for U2F:
1) "practically nobody is doing that" - TOTP.
The "tech bubble" is not an insignificant number of people.
2) "barely supported by anyone" - U2F.
If you look at the link I posted there are a number of services with extremely large user bases that are supporting it.
Count # downloads of G Authenticator on Play Store - ~10M. To 4B of internet users.
By anyone I meant platform support. U2F on iOS? U2F outside Chrome? etc.
The MS authenticator has between 1,000,000 and 5,000,000 [2]
These stats are just for Android devices not iOS.
10's of millions of users is not insignificant. Why does the global number of internet users matter here?
[1] https://play.google.com/store/apps/details?id=com.google.and...
[2] https://play.google.com/store/apps/details?id=com.azure.auth...
https://support.google.com/googleplay/android-developer/answ...
The iOS App Store has literally dozens of TOTP apps. I imagine the Play Store is the same.
In addition, the web client seems defective, you "create an account", and then get a control panel, and have to go back and try the login again on the original demo. Very counter intuitive.
3rd party software is getting better sandboxed every year, hopefully it soon will be in Mac App Store.
Counter intuitive parts of enrollment will be fixed.
It's a great concept but currently somewhat limited to government and financial services, I would love to see something similar get good traction!
This is another password=kdf(site data, master pwd) protocol.
In any case, I strongly believe these things should be managed by user agents: https://www.w3.org/TR/webauthn/
While I understand the single master key way makes it trivial to manage multiple clients, it is a non-starter as far as I'm concerned since you cannot rotate it once you've used it as a credential on multiple services. And what about revocation? If you support neither rotation nor revocation, each credential must be independent or you are painting yourself into a corner.
Why replace OAuth? because it sucks. It's stateful on the server, and it's security surface is bad. With SL you could sign a token for client=me provider=facebook scope=profile,photos,friends expire=3months. and all that would be stateless w/o any extra code on the server of identity provider. It is a huge step over OAuth code which is often full of holes (see Doorkeeper in Rails)
As for your example, you can do exactly the same thing with OAuth client assertions: https://tools.ietf.org/html/rfc7521
OAuth implementations being buggy is a valid point, but why wouldn't the same apply to SL or any authz protocol?
With OAuth you add a lot of extra code in your app. Like storing client_id client_secret and you need grant dialogs etc. Have a look at this demo (any account with web version):
https://securelogin.pw/#provider=http://facebook.com&client=..., Locations
With NO code any website could ask access to other provider. Little code on the server side needed. Granular permissions. Etc
You mention automation, which is good, but you may not be able to rely on it succeeding. Until every client website has responded to the change request, you must keep around or remember the old passwords.
For automation you also have to store the list of websites you've registered with somewhere. Since your system works on multiple clients, that place has to be central.
My point was that the protocol to "refresh" a website account with a new master pwd only solves part of the key rotation (=master password change) story.
As for OAuth, I don't agree with you that it is onerous. Yes, client_id and secret are poor mechanisms, and better ones will emerge. But there are many cases where you absolutely want to authenticate the client (it might not always be the user's own browser) in addition to the user/grant.
>For automation you also have to store the list of websites you've registered with somewhere. Since your system works on multiple clients, that place has to be central.
The plan is: until we have 1000+ origins using the protocol, there will be a manual list of origins that will be tried for reset. After that, it will be sorted out with a central server and encrypted list of origins. Sounds good?
> you absolutely want to authenticate the client (it might not always be the user's own browser) in addition to the user/grant
Cool part is you still can. Provider can look at "client" the token was issued to, and reject if it does not match with some authorized Client record in the database. It's rather flexible for any scenario.
But what was meant is the SMS service they make money on.
In short, providers are rather too willing to transfer a mobile phone number.
> Authy and SMS are vulnerable to phone porting attacks. Device based Authenticator apps like Google Authenticator mitigate this by being linked to your device, not your phone number.
Because every website is different everyone has different requirements, and a solution would be to just use the public key as the identifier instead of the email.
And for backup purposes as master password, I would suggest making it very similar to Trezor and generate for the user with a good RNG a 24-word mnemonic. I know is a hard task to write down for some but you don't do it every day, and you know you're safe if you lose your device or make use of it on a different device. I wouldn't want to rely on the user to memorise it or generate it, especially when users do not generate a good entropy.
I would personally recommend using Trezor as guidance. This is my demo: https://cl.ly/1P0N0W1t1a3B
I would be happy to implement it in my systems if it follows the principals above.
it's exactly how it is now. Email has no "weight", it's just a label.
What are your systems? What about 24-word mnemonic as a second option? I personally hate those, and don't want to enforce it.
In terms of master password, what do you think is easier to write down as a backup?
This: ?A[ZSOO{PBs&Y]5.6iwm=_t}]t<DOk
Or this: remove maple runway unable empty little swing zebra lava interest secret admit
To create this you can even use the bitcoin libraries, so you don't have to write your own, and you will only need to work on the clients.
If you do it similar to what Trezor did but on a desktop app, you're protocol is built for the web pretty fast. If is good for money is definitely good for Facebook/Twitter/whatever.
If you don't have a lot of experience with bitcoin, you can try to use https://copay.io/ is cross-platform, open source and very secure. Exactly what you're after from my understanding.
You can even change this remove all the bitcoin wallet stuff and make it as an authentication app. It generates the words for you and forces you to back them up to avoid any pain later on. This follows all the principles mentioned.
P.S. This version is visually better imo https://github.com/bitpay/copay/releases/tag/v2.7.0
SecureLogin = function(scope){
function toQuery(obj){
return Object.keys(obj).reduce(function(a,k){a.push(k+'='+encodeURIComponent(obj[k]));return a},[]).join('&') # user is given 20 seconds to approve the request
20.times{
sleep 1
sltoken = REDIS.get("sl:#{state}")
break if sltoken
}
I have no reason to think it's unacceptable, was just curious. Interesting project!
The client worked with QR codes so you could login with just your phone. The app would verify authentication using a websocket/long-polling so as soon as you scanned the QR code you'd be logged in. Most banking apps now use a similar technique, which is a good UX imho.
Any credential I can't change is a credential I won't consider.
I mean I don't want to change it ever month, but maybe every 3-5 years?
The offline password doesn't use an encrypted database, but instead used a key-derivation function based on a master password and e.g. the service name to get deterministic passwords.
In the case of a password manager, there are issues with password requirements and service name reuse. Here, by switching to a signing protocol, those issues are mitigated. At the same time, because this isn't the password protocol, it forces users to use this app. Meanwhile, you can't force users to use a password manager, leading to horrible password reuse.
The big downside I see is the immediate compromise upon revealing your master password. In the case of a PW manager, your opponent needs to get to your database first. This might give you time to roll-over your passwords.
Another thing I don't see is key-revocation. What to do when you fear your master password is compromised? That might just be done by essentially the same as a password change though.
This combination would solve the problem of your master password being disclosed (your opponent still needs to get your database), while retaining the benefit of giving sites only your public key instead of a usable password.
Seems like a good feature for people with stronger security requirements (eg, journalists), but not the average user.
So the average user can stick with the default app, while anyone who wants more security can opt for a vault-based version. This is similar to the current state of affairs with passwords, where users can opt to use password managers.
The important thing is that sites make the shift to a challenge-based protocol. Once that's done, there are lots of different ways of implementing the client-side app, all with different trade-offs. For example, you could replace the master password with a fingerprint.
There's a button "Change SecureLogin" which essentially replaces old pubkey with new one. One would have to do it with all services they every used, and do it before the attacker. It could be automated though.
> The big downside I see is the immediate compromise upon revealing your master password
On this problem I wrote another blog post https://medium.com/@homakov/why-brainwallet-are-great-for-cr...
I believe having to worry about 1 thing is better than 2. It's losing (usability) > stealing (security) in this problem.
But otherwise you summed up everything properly, just what I was trying to say.
After you changed you can get into the same account using your 2nd profile only. Ignore the email: site owners are free to confirm it, but playground does not.
And if it's just a label, then maybe it should be advertised as such. I see what you're saying now, but that's not obvious from the app.
You can quite freely backup the password vault, because pure access to it isn't the end-all-be-all. It's essentially a second factor.
I'd also like to compare this to a simpler challenge-response based protocol. Have the shared secret be e.g. SS = scrypt(hmac(passwd, serviceID)), and the challenge be nonce, to which one should respond hmac(SS, nonce).
The biggest difference I see is the issue of leaking the shared secret. It doesn't leak anything about the passwd, but compromises access to the service. If your public key leaks, that still can't be used to authenticate you with the service. If I'm not mistaken, the shared secret approach has the advantage of better privacy.
"All user data stored on the persona.org services will be destroyed, including registered email addresses and password hashes"
And hey, there's nothing on SL servers.
Then you can see the headers that are exchanged. https://www.grc.com/sqrl/diag.htm
So of course, we get the ridiculous statements like:
- complaining that TOTP provides a system for fallback codes. The author didn't write them down, and of course they're stupid and pointless and let's quickly forget about them because his "solution" has literally no fallbacks.
- responses in this thread where the author says "well what if a bank just steals your money?", when someone mentions that even credit cards are easier to revoke: you can call the bank to cancel the card.
- responses to questions about it's open source status (because no License was specified) that seem more like a fucking lunch order at Subway: "which one is your favourite?". This leads on to one of my favourite bits in this thread:
- This absolute gem (emphasis mine), from the author who claims it's "production ready for four billion people":
> I don't want to have any rights or responsibility, just Do Whatever You Want license.
The author loves to dismiss current solutions with weird anecdotal evidence. He freely admits he doesn't use TOTP on many sites, even when it's available. He never "signs out" of applications. He claims that users "don't care" if their account on a site is breached.
For reference, the "current solution" that I believe still beats this system is:
Password managers, with a secure "master" (i.e. keychain on iOS is unlocked by TouchID/ system pin) combined with TOTP are achievable, don't rely on a fucking electron app, and provide fallbacks if a 3nd factor authentication device is lost.
But ultimately all of that is just gravy when you look at the most basic of irony in this whole thing:
The author's stated goal is to remove the need for passwords, because user's don't create strong passwords, they write them down, etc. His "solution" to that, is a system whereby users entire (for sites using this system) security is based on a single pair: email address, and a "master password" that, you guessed it - the user HAS TO REMEMBER.
I'll leave you with one final though: if this ever gets any real-world usage, how long until bad actors start gaming the system, by presenting "Proceed with SecureLogin" buttons that show a dupe of the existing web UI to convince users to enter their email/password, and then hey presto, they have access to all SecureLogin-enabled sites that user has an account on.
Edit: formatting.