Do not use! SecureLogin for existing web is not maintained and soon will be part of a whole new approach based on a blockchain.
Reasons:
-
Lack of incentive from website admins to implement this protocol and put initial friction on shoulders of the users
-
The web and Chrome app versions compromise on security too much, and the desktop version is way too heavy. New version is getting rid from electron and uses pure node.js
-
New protocols are not being adapted if you don't give 10x improvement. SecureLogin by itself wasn't 10x.
Now SecureLogin is merely 'login' a method exposed in Fairlayer blockchain. A website can request it, and after the user confirms the JS gets back a token consisting of pubkey and signature of current origin. Difference from original SecureLogin:
-
No more provider & client. Client different from provider is only useful for OAuth like interactions, which would be a long way after making this popular for traditional login
-
No more secret & hmac given separately - pubkey does the signing job.
-
No more timestamp - if you managed to obtain the signature once, you could do it again.
-
No more scope - scope could be useful in financial apps only, and fairlayer itself has payments inside.
So it's not dead, but re-incorporated as simple API into something that has much more potential, has monetization model and fixes much more important problem than merely authentication on the web.
Before you dig into details, try the demos: Rails demo, Node.js demo
SecureLogin is a decentralized authentication protocol for websites and apps. Classic passwords/2FA are poorly designed, hard to backup and inconvenient to use. SecureLogin is an all-in-one solution that creates a cryptographic private key from your email and master password to sign in everywhere and helps you to forget about passwords.
Blog post on 1.0 release and our Principles.
Here are major problems it solves:
-
Password reuse: SecureLogin's #1 goal is to fix password reuse and simplify authentication process. It should work for everyone, not only for geeks.
-
Convenience: existing onboarding process is a disaster for conversion: Email, confirm email, password, confirm password, wait you need one digit and one capital letter, think of a new password, sign up and go to email box to click "Confirm My Email" a 1000th time in your life. With SecureLogin, it's just two clicks.
-
Centralization: Currently every account depends on an email, which can be used to set a new password. Email is very centralized - majority uses services like Gmail. This is even worse for SMS, which is owned by telecom corporations. This attack is currently exploited in the wild only against political activists, but there's no need to wait for someone to hack a major email/SMS provider – with SecureLogin there's no central authority, no central server and no way to hijack your account.
-
Man-in-the-Middle: interaction of the user computer and the server is often compromised in between: broken HTTPS, CloudFlare, malicious browser extensions, Man-in-the-Browser and XSS can be prevented when the user explicitly signs every critical transaction.
-
Malware: SecureLogin 2.0 with Doublesign stops malware trying to act on behalf of your account – usually to steal your money. Doublesign is like a "two man rule" - the server must verify two signatures of "scope" which includes every detail of the transaction e.g. SWIFT, amount, currency, account number or Bitcoin address. The entire transaction is signed on both devices (usually desktop + mobile) so compromise of one of them wouldn't be enough to empty your bank account (unlike how it is now).
-
Phishing: Many security experts tend to say phishing is the problem of the users not looking at the URL they type their password on. It's totally wrong. We belive phishing is an extremely important problem and we built-in the protocol in a way to make phishing impossible: every message is either sent to a Web/Extension via postMessage, revealing real
event.origin
or to a native app viaws://127.0.0.1:3101
revealingOrigin
header.
SecureLogin is not a OAuth or Single Sign On like Mozilla Persona or Facebook Connect, not a password manager, not a new 2FA option. It's all three in one protocol.
Let's list all popular auth methods and some esoteric ones to see how they deal with these problems for normal users.
Please note, password managers are not in the table because there's no such thing as a "password manager auth method" - a manager is merely not enforceable. However there is tiny 1% of password managers users.
Scheme | Decentralization | Usability | Anti-Malware | Anti-Phishing | Cost / Scalability |
---|---|---|---|---|---|
Standard | Email provider can set new pw | Poor | No | No | Free |
Standard + TOTP | Decentralized | Poor UX and backups | Delayed, not prevented | No | Free |
Standard + U2F/Yubikey | Decentralized | Worst UX, no usable backup | Delayed, not prevented | No phishing | $18+ per dongle |
Standard + SMS / Authy / Duo | "2nd factor" is a CA. Vendor lock-in | Overhead UX | Delayed, not prevented | Not fixed | $3+/mo/user Duo, $0.1/Authy request, $0.05/SMS |
Magic Links on Email / Mozilla Persona | Email provider is CA | Greatly improved UX: (see Slack or Medium) | No | No phishing | Free |
OAuth / OpenID / SAML / SSO | Identity provider controls your account. Vendor lock-in | Best UX: 2 clicks | No | No phishing | Free |
SecureLogin | Decentralized | Best UX: 2 clicks | 2.0 has scope-specific signatures | No phishing | Free and Open Source |
See Protocol Specification (being finalized now)
Check out real verification Ruby code for our Playground. Please get in touch for any help with implementation.
gem install securelogin
Help needed for implementations for top 20 of hot frameworks
First, market penetration rate of password managers is a joke - less than 1%. You may use it, some of your friends may use it, but the rest of the world does not and will not. They are not enforceable on your users.
Second, they are very inconvenient, especially on mobile. They try to look like a human, looking for inputs and prefilling them. SecureLogin makes websites to implement well defined authentication protocol instead.
Most popular managers are not even open source and cost money. Using closed-source software is a giant no-no for this kind of product.
But more importantly, they do not solve the problem that all our accounts belong to centralized email services via "Reset my password" functionality.
Yes, like in all password managers, there's no way to recover your private key without a password or recovery key.
There's a common misunderstanding that email is any different: try to reset your Gmail password now (backup email doesn't count as it's just turtles all the way down).
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.
Although the web version exists, no one should use it for anything serious. Users should install native clients which don't depend on the securelogin.pw web server and generate private key much faster than JavaScript.
The protocol and the client are completely open source. They are free now and they will remain free in the future. There is no monetization plan except the one where Sakurity gets more clients for saving the Internet from a two-decades long problem.
It is not even technically possible to start charging money for anything: the protocol works client side, no external servers, no API. It's not a promise, it's a fact.
It supports desktop and native apps as well. But due to the fact that custom protocols are not registered in a public repository like domains, provider/client parameters are limited to web origin format. You're free to pass sltoken
back to your app:// from your web-based client
URL.
Currently it's ~600 LOC in JS and 200 LOC in HTML. Most programmers can audit it in an hour. There are instructions to build it for all platforms, and we're doing our best to implement reproducable builds as soon as possible.
Just click inside the app and change it. See wiki https://github.com/sakurity/securelogin/wiki/How-password-is-changed
The core functionality of SecureLogin is based on opening the native app, getting a signed sltoken
and returning user focus back to the same page. It's not easy at all.
Chrome, Firefox: great. In Full Screen mode it's possible to focus back using alert() in Chrome (in Firefox alert does not focus)
Safari: OK. No way to avoid 'Do you want to allow this page to open “SecureLogin.app”?' dialog every time. 3 clicks required. Requires extra HTTP server for proxy page.
TorBrowser: SecurityError: The operation is insecure
when trying to open securelogin://
Edge: does not support custom protocol handlers like securelogin://
. At all. They don't provide any roadmap. Use the Web version.
Chrome, Firefox: great.
All-in-all iOS and Safari are quite hostile to the flow SecureLogin uses on all other platforms.
It takes 5 clicks to get through regular login experience, while just 2 for all other platforms:
-
SecureLogin button. opens a window that has another button to open SL client
-
clicking second button opens third window (yes, it's required) where Safari finally asks to open the App
-
Confirm opening, now HTTP & WS servers are running. 2nd tab is redirected to :3102/proxy.html and sends a message to WS with auth request
-
Confirm request inside the app
-
Press tiny "Back to Safari" sign in top left corner of the screen.
Only 1 and 4 are required on other platforms. Due to bad UX and Safari not following the spec we drop iOS app for now. Users should use the web app (security of a native app on iOS is actually imaginary - the platform is way too closed down). We will iterate back to it and try to fix it with Action Extension for Safari (the way 1Password works right now).
Chrome: great.
If you want to, side-load the CE directly from this repository. Preserve "key"
inside manifest.json - it keeps chrome-extension URL static.
zip -r www.zip www -x *.git*
Don't forget to ignore .git when packing for Chrome Store.
Cordova is used for iOS and Android platforms. It's not exactly a smooth platform, and there will be native clients in the future, but it does the job.
cordova create sl SecureLogin
cd sl
cordova platform add android
cordova platform add ios
cordova plugin add https://github.com/Crypho/cordova-plugin-scrypt.git
cordova plugin add cordova-plugin-customurlscheme --variable URL_SCHEME=securelogin
cordova plugin add cordova-plugin-splashscreen
cordova plugin add cordova-plugin-whitelist
cordova plugin add cordova-plugin-device
Plugins are ready, so last step is replacing www with our codebase:
rm -rf www
git clone git@github.com:sakurity/securelogin.git www
Now you can use cordova run ios
/ cordova run android
Electron is employed for macOS, Windows and Linux apps.
Use this repository. Here are some useful commands for building packages for distribution.
Outside of Mac App Store
electron-packager . "SecureLogin" --osx-sign --overwrite --arch=x64 --icon=www/electron.icns
electron-installer-dmg SecureLogin-darwin-x64/SecureLogin.app SecureLogin
For Mac App Store
electron-packager . "SecureLogin" --platform=mas --osx-sign --overwrite --arch=x64 --icon=www/electron.icns
electron-osx-flat SecureLogin-mas-x64/SecureLogin.app
For Windows
electron-packager . "SecureLogin" --overwrite --arch=x64 --platform=win32
See Issues and Projects.