
SecureLogin Authentication Protocol 1.0 - digitalnalogika
https://medium.com/@homakov/securelogin-forget-about-passwords-c1bf7b47f698
======
buro9
I run a fair number of sites, and I don't want to hold people's passwords.

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/](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.

~~~
homakov
>1\. how this works

So if you are a developer, your best bet is "How it works?" here:
[https://github.com/sakurity/securelogin](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/](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.

~~~
AbacusAvenger
It bothers me a bit that the project has weak commit messages like this:

[https://github.com/sakurity/securelogin/commit/975332ae0b0e2...](https://github.com/sakurity/securelogin/commit/975332ae0b0e290d27fdefb66d66f5bc7c784712)

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").

~~~
amingilani
From what I can tell, it fixed issue #1

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.

~~~
nmjohn
> 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.

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.

~~~
homakov
Nevermind initial technical sync commits, not my fault Git requires -m.

~~~
cyphar
It doesn't. `git commit` will open your $EDITOR to let you modify the full
commit message. I would recommend looking at how Linux kernel commit messages
are structured.

------
tptacek
I'm a little unclear on how this is more than a serverless password manager
with Nacl public keys instead of some symmetric algorithm generating per-site
passwords.

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?

~~~
homakov
Thomas, many times I made a point that if auth solution is not enforceable
it's not going to be popular. You like 1Password and it has reasons to be
loved.

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.

~~~
tptacek
I'm not saying people should use 1Password instead of this. I'm actually not
recommending anything, just trying to get my head around the concept. Reading
the Github page, the impression I was left with was that this was essentially
the same thing as an auto-installed site-specific serverless password manager.
Is that incorrect?

~~~
homakov
It's mostly correct, but it really is not a password manager. Manager is a
helper for some people, protocol is a requirement for all. So I want to draw a
line between protocol and a manager.

It's like [https://getclef.com/](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.

~~~
md_
I like the little details. And unlike Steve Gibson's SQRL--which I was
trashing recently for being overhyped--you don't come off as a dick. ;)

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.

~~~
homakov
1\. Will try. it would take 2x much text.

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".

~~~
md_
2: What I was trying to understand was whether a malicious site can relay the
"securelogin://" challenge generated by a good site to the victim. Basically,
an XSRF attack. Does the client validate the context of the challenge?

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://](https://) scheme--you
could avoid that, no?

~~~
homakov
2\. Not XSRF but phishing? Yes, [https://github.com/sakurity/securelogin#anti-
phishing-concer...](https://github.com/sakurity/securelogin#anti-phishing-
concerns) \- it only works for callback=ping and native apps

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.

~~~
md_
2\. Phishing and XSRF are effectively the same in this case, no? We're talking
about the phisher relaying the challenge to the victim and tricking them into
posting the response--which doesn't really require phishing per se, hence the
XSRF. Again, I may be misunderstanding the protocol here. :)

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. ;)

------
iafan
This is a very interesting concept. I'm pretty sensitive to UX issues, and I'm
yet to see nicely implemented and secure auth flows. All non-OS-native 2FA
solutions (Google Auth, Duo) seem a bit cumbersome (and require additional
efforts to implement and to setup for the average user). Apple does auth right
with their Touch ID (both for logging in and to confirm transactions). I see a
potential for SecureLogin to be as close to that Touch ID user experience as
possible.

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/](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.

~~~
lobster_johnson
The enterprise version of Duo apparently works by having the mobile app wake
up to ask you for confirmation for the login -- similar to how Apple's Touch
ID automatically opens to confirm things like Apple Pay if you initiate from
the desktop -- rather than making the user open the app, select the account
and generating a number.

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.

~~~
iafan
Yeah, I'm an every-day-user of enterprise Duo app. It is as good as a third-
party app can be (on iOS specifically), yet you have to do extra steps as
compared to Touch ID alone: force-press the notification, click Accept, then
confirm with Touch ID. The first steps out of two are just a limitation of how
apps work in iOS. If your phone is in sleep mode, you will miss the
notification as well. Such things really need to be implemented on OS level.

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.

------
danjoc
Tried demo on chromebook. It failed. Read github. Requires native app...
written in JS? Relies entirely on single password that can be forced out of
me. No mention on how to sync across devices. Nice try. I think it has a lot
more to work out.

"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.

~~~
homakov
> Tried demo on chromebook

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?

~~~
danjoc
>But web app must be working, just press Cancel if app is not installed.

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...](https://www.recode.net/2016/6/8/11883518/app-boom-over-snapchat-
uber)

~~~
homakov
>I want to try your thing, so I press cancel? That doesn't seem terribly
intuitive. I thought your main selling point was usability.

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.

~~~
danjoc
>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 :)

------
zwily
I like the idea, but the master password scares me a bit. So if I accidentally
type my master password into Slack one day (not that that has ever happened),
it seems anyone who saw it would then immediately be able to log into every
website using SecureLogin as me.

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.

~~~
curioussavage
I don't think this criticism is that valid. LastPass et al are the same. After
years of use I have no idea how someone would do that.

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.

~~~
notzorbo3
I've typed my most sensitive password on public IRC once. I assumed my screen
was locked while my display came back to life after sleep mode. For some
reason, my screen wasn't locked and the IRC window had the focus instead.

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.

~~~
ezfe
Yeah, I've done this as well. Texted someone my laptop password because the
macOS beta I was using had a delayed auto-unlock bug and I thought it had
failed.

------
geezk7
homakov, a lot of work need to be done:

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.

~~~
arekkas
Other blog entries suffer the same thing, for example
[https://sakurity.com/blog/2017/04/24/owasp.html](https://sakurity.com/blog/2017/04/24/owasp.html)

~~~
btasker
Oh god, there are so many things in that post which make me sad.

> 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.

------
ben0x539
This is a pretty cool scheme, but I'm not sure about the UX argument. The
login flow itself is good UX, but it's arguably just the happy path, and now
I'm responsible for irreplaceable data on my device. My device might fall into
a river, or a customs lockbox. I can mitigate that but then I'm doing manual
secrets management work that "eh, I'll just trust my email provider" would
have prevented.

~~~
level3
It seems like your device is completely replaceable in this scheme. The
keypair is derived solely from the email address and the master password, so
you can just generate the same keypair on a new device.

~~~
homakov
Exactly - everything can be derived from password. It's simplest backup
strategy possible.

~~~
ben0x539
Ah, so it's like sharing one password for everything?

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.

~~~
homakov
There are many differences, because your password used just once to create
root hash. From root hash private key is generated, and no one is sharing
password anymore

------
joshka
My email address is not my identity.

[https://github.com/sakurity/securelogin/issues/3](https://github.com/sakurity/securelogin/issues/3)

------
Osiris

        > Cryptographic key never leaves your device
    

Isn't that a huge usability issue? I use multiple devices, phone, laptop,
desktop. How do you propose being able to log into the same website on more
than one device if the key is on the original device?

Also, have you reviewed Web Authentication specification? It sounds very
similar.

~~~
Operyl
So, that's kind of a weird half truth. The key is determined from your email +
master key, and will always be the same as long as those two details are the
same. The downside, and what I'm not a fan of, is neither can be changed
without massive work. At least, that's what it seems like based on the README
but it might be a little vague ...

~~~
stephenr
> The downside

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.

~~~
homakov
> What about offline generation of thousands/millions of combinations

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.

------
skion
Yes! As a site admin in today's world, you should indeed not want to store
passwords. Or even personal data for that matter.

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/](https://www.authentiq.com/)

~~~
homakov
> I'm very keen to see if we can add support for the OP's authentication
> protocol soon

It doesn't sound plausible, it only works without a middlemen.

~~~
skion
There are probably several angles on this. One is to let our Authentiq ID
mobile app support and sign in to SecureLogin sites. Another to let websites
that use Authentiq automatically support sign-ins with SecureLogin. These look
feasible at first sight.

A third, replacing our current auth flow with SecureLogin indeed isn't likely
to work for reasons you mention.

------
bogomipz
I had a question about the following passage:

>"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:

[http://www.dongleauth.info/](http://www.dongleauth.info/)

~~~
homakov
Supporting != users are using it. Especially outside of tech bubble. I myself
always cringe when forced to setup TOTP. Yes, I seriously would rather take
the risk of my gmail reset compromise than dealing with TOTP again.

~~~
bogomipz
They were two different sentiments:

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.

~~~
homakov
>The "tech bubble" is not an insignificant number of people.

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.

~~~
bogomipz
The count of Google Authenticator in the Play store is between 10,000,000 -
50,000,000 [1]

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...](https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en)

[2]
[https://play.google.com/store/apps/details?id=com.azure.auth...](https://play.google.com/store/apps/details?id=com.azure.authenticator&hl=en)

~~~
homakov
It's number of downloads btw. Some might have downloaded it once and never
used, some could have used for just one app, some removed and downloaded
again.

~~~
Operyl
Err, I thought users are deduplicated in that case (at least on android's
store).

~~~
bogomipz
Yes you are correct they(installs) are uniques. See "install-related
statistics":

[https://support.google.com/googleplay/android-
developer/answ...](https://support.google.com/googleplay/android-
developer/answer/139628)

------
Vendan
If you hit OK that you have the client, but you actually don't, suddenly you
can't do anything at all on the website... Also, imo, asking to install an
app, no matter what app, is going to be way less likely to happen then any
other kind of login, as I don't like putting trust in random third party
software.

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.

~~~
homakov
Thanks for a fresh look. Yes, first encounter can be putting off. Clicking
"OK" makes it open local app which you don't have, but it would be silly to
have "clear localStorage" button right?

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.

~~~
Vendan
Also, do all of the companies linked to on
[https://sakurity.com/securelogin](https://sakurity.com/securelogin) actually
support this protocol? If not, linking to that page as "Who supports
SecureLogin now?" is a bit disingenuous.

------
TrickyRick
Great idea! Exactly this is implemented across pretty much all "important"
services in Sweden (Tax office, banks, pension funds, money transfers etc),
it's called BankId: [https://www.bankid.com/en/](https://www.bankid.com/en/)

It's a great concept but currently somewhat limited to government and
financial services, I would love to see something similar get good traction!

~~~
arnarbi
BankId is not even close to this. It's a centrally managed PKI, which exists
in many countries.

This is another password=kdf(site data, master pwd) protocol.

~~~
homakov
Not another... It's more flexible kdf(site data, consumer, scope, expiration,
master pwd) protocol, allows to prevent many other attacks and replace OAuth
all in one.

~~~
arnarbi
Why replace OAuth? That's an authorization protocol. Do you mean OpenId
Connect?

In any case, I strongly believe these things should be managed by user agents:
[https://www.w3.org/TR/webauthn/](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.

~~~
homakov
Check "change password" section for rotation of one profile to another. It's
quite simple

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)

~~~
arnarbi
An update operation is one part of a solution. Are passwords versioned? You
will eventually get into a state on some client where you have changed the pwd
N times since last talking to a particular server. Does that client have to
keep around N passwords to be able to update it? That defeats the purpose of
rotation, which is to fully retire an old key.

As for your example, you can do exactly the same thing with OAuth client
assertions:
[https://tools.ietf.org/html/rfc7521](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?

~~~
homakov
I can't understand first paragraph, especially "versioned" passwords. Every
profile is result of generation, and you can change profile (manually or
automatically) if you think it was compromised.

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=...](https://securelogin.pw/#provider=http://facebook.com&client=http://locateMyFriends.com&scope=Share%3dFriends),
Locations

With NO code any website could ask access to other provider. Little code on
the server side needed. Granular permissions. Etc

~~~
arnarbi
With "versioned" passwords I mean a way to detect when a site hasn't been
updated after a master password change. Presumably you need the old password
to generate the old key, which is used to sign the change request. If you've
changed your password multiple times since you last spoke with that website,
how do you know which old password to use.

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.

~~~
homakov
That's what made me confused. There is no way to "change" password, only to
create a new profile and migrate to it. And you can have many profiles at the
same time (some with equal email).

>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.

------
therealmarv
Why is Authy called unsafe by the Author and Google Authenticator safe? Ever
heard that it is more likely that your smartphone gets lost, broken and stolen
than your precious online account getting hacked? I'm very happy I had Authy
when I was in a foreign country and my Nexus 5X stopped working (BTW: damn you
LG for your poor engineering!)

~~~
homakov
Authy service (one where they send you SMS) is centralized. It's not that it's
safe or unsafe, but generally decentralized is better option.

~~~
zwily
Authy also can backup your TOTP tokens (encrypted with passphrase on device).
This is super handy when switching devices, but weaker than Google Auth where
the TOTP private bits never go back to Google in any form.

~~~
homakov
Yes, sorry, that TOTP backup thing is great. Always hated that GAuth cannot
back up.

But what was meant is the SMS service they make money on.

------
florincm
I think your idea is brilliant but needs a bit o polishing off.

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](https://cl.ly/1P0N0W1t1a3B)

I would be happy to implement it in my systems if it follows the principals
above.

~~~
homakov
>to just use the public key as the identifier instead of the email.

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.

~~~
florincm
I understand is a label, but some bad devs might use it as a way of matching
the user, and end users might get confused especially when you can write any
email as there is no verification for it in place. Let them choose it, or you
make the first one to speed up the process and let them edit it if they don't
like "Account 1".

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/](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](https://github.com/bitpay/copay/releases/tag/v2.7.0)

------
missingencoding
Hey homakov, nice work. might want to remember to encodeURIComponent() around
the keys as well:

    
    
         SecureLogin = function(scope){
           function toQuery(obj){
             return Object.keys(obj).reduce(function(a,k){a.push(k+'='+encodeURIComponent(obj[k]));return a},[]).join('&')

~~~
homakov
Thanks! internal toQuery works with predefined a-z keys only so I think it is
ok to be this way?

~~~
missingencoding
better safe than sorry, as I'm sure you know ;)

------
purvis
I'm not too familiar with ruby/rails, but does this mean the HTTP request just
sits open for up to 20 seconds? Is this common/acceptable practice?

    
    
        # user is given 20 seconds to approve the request
        20.times{
          sleep 1
          sltoken = REDIS.get("sl:#{state}")
          break if sltoken
        }
    

[https://github.com/homakov/cobased/blob/master/app/controlle...](https://github.com/homakov/cobased/blob/master/app/controllers/application_controller.rb#L18)

~~~
homakov
It's not common, but the quickest way I could find to reduce # of roundtrip
requests. Happy to hear why unacceptable.

~~~
zwily
It just means you're tying up a thread (or whole process, if your rails app
isn't running with threads) waiting for the response.

~~~
homakov
It's not a requirement though: one may ping from the client side with
setInterval.

------
jtwaleson
Cool. I created a similar protocol a couple of years ago but it never got
beyond a weekend project, see here for a diagram:
[https://github.com/jtwaleson/vault](https://github.com/jtwaleson/vault)

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.

------
jimktrains2
How does revocation work? It sounds like a pain, almost as much as currently.

Any credential I can't change is a credential I won't consider.

~~~
homakov
It's not a pain, can be 1 click if you're on the same device (with log of
websites you used). [https://github.com/sakurity/securelogin#7-how-do-i-
change-ma...](https://github.com/sakurity/securelogin#7-how-do-i-change-
master-password) Harder if on a fresh device, but totally doable for anyone

~~~
jimktrains2
So it needs to be done with each site. That isn't feasible. I either need to
do each one individually all at once or risk forgetting the password for
lesser used sites.

~~~
homakov
Let me think of a solution. Usage origins could be tracked and stored server
side, trivially, but not sure if worth the hassle.

------
Gehinnn
How does it compare with SQRL? What does SecureLogin better? It like SQRL's QR
code approach very much so that you can easily go to a public computer and
login by just using pointing your phone to the screen.

------
JepZ
TLDR: One password for all pages without telling any page the actual password.

------
aruggirello
About time that this gets addressed where it should - in the browser:

[https://www.w3.org/TR/webauthn/](https://www.w3.org/TR/webauthn/)

~~~
homakov
I've looked closely after standards in auth area and left very disappointed.
They are painfully slow. FIDO is founded on 2013, and they never tried to get
rid of passwords, but only sell overpriced plastic sticks. I doubt webauthn
will be less bureaucratic

------
mtarnovan
Interestingly, a few days ago Google Authenticator asked me if I wanted to
switch to a simple confirmation (instead of manually entering the 2FA token).

~~~
voltagex_
I'm guessing that's only supported with Google services though.

~~~
mtarnovan
Indeed, at least for now.

------
JepZ
How do I change my master password?

I mean I don't want to change it ever month, but maybe every 3-5 years?

~~~
homakov
[https://github.com/sakurity/securelogin#7-how-do-i-change-
ma...](https://github.com/sakurity/securelogin#7-how-do-i-change-master-
password)

------
ben0x539
Curious to read more about the planned DoubleSign thing, not sure if it's
spelled out anywhere.

~~~
homakov
So DoubleSign is pretty cool for financial apps because it signs `scope` on
two devices. First prototype had that feature. But it was very unclear to the
users. So it was removed, but will be added back if this 1.0 version gets used
by well... anyone at all :)

------
leni536
What about making client side public key auth not a UX disaster in all major
browsers?

~~~
homakov
In my opinion SL does exactly that: another take on client side public key
auth. It's not built in the browser on purpose for flexibility.

------
tchow
I don't see any discussion about what this does besides decentralisation. Care
to explain how it is securing through decentralisation? Is this some
blockchain based solution?

~~~
rocqua
It's essentially the offline password manager idea with some kinks worked out.

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.

~~~
homakov
> Another thing I don't see is key-revocation

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...](https://medium.com/@homakov/why-brainwallet-
are-great-for-cryptocurrency-ff73dd65ecd9)

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.

~~~
zwily
I tried the "Change SecureLogin" flow, and it's not obvious to me how that
works if I'm changing my master password. It lets me select a new profile from
within the app, but won't that also change my email address?

~~~
homakov
Right now email is not changed, because it's not used as primary key, it's
just a label like your fullname.

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.

~~~
zwily
I did try to create a new profile with the same email address and it didn't
let me, so it does appear to be treating it sort of like a primary key.

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.

------
kennydude
This, to me, sounds like Mozilla Persona

~~~
floatboth
More like SQRL, but without the ability to authenticate from a different
device (smartphone)

~~~
homakov
Yes, you can only auth from current app installed on current device. No QR
codes involved :)

------
borplk
How does this compare with SQRL?

~~~
homakov
I couldn't find any working clients of SQRL/demo? Will happily add it to
comparison table.

~~~
botto
I use the android SQRL client
[https://play.google.com/store/apps/details?id=net.vrallev.an...](https://play.google.com/store/apps/details?id=net.vrallev.android.sqrl)

Then you can see the headers that are exchanged.
[https://www.grc.com/sqrl/diag.htm](https://www.grc.com/sqrl/diag.htm)

------
stephenr
I'm already highly sceptical because of the authors previous "solutions" for
"a password replacement": just rely on one time password links via email. When
the subject of mailbox security is mentioned he responds with "I'm not trying
to solve _that_ part of the problem". Right.

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.

