I tried to click on the SL icon in the Chrome toolbar, and it appears to be trying to do something (showing blank popups for parts of the second and then closing them), but in the end nothing happens.

Hey,

One problem of deterministic schemes is that it can't store variable data. This especially becomes an issue when you need do deprecate or refactor the scheme used for password generation. A change means losing access to existing logins.

I would suggest versioning the hashing schemes, and creating a way of communicating the scheme version between the requesting and signing party. SL will always incrementally add hashing schemes while maintaining support for older ones. When a requesting party requests a deprecated hashing scheme; the password is hashed according to this scheme; but a update of the password is also sent to the requesting party along with the new version number.

This way requesting and signing parties maintain backwards compatibility and granular upgrading.

A point of concern with this would be requesting known weak schemes to attempt cracking the result. This could be solved through TTL (expiration dates) of older schemes in favour of the latest schemes. If an older scheme is requested past the TTL time frame, SL can either refuse hashing or display a warning to the user that the website is using an outdated scheme.

I like the comparison table in the READMe, and would love to see a comparison to Steve Gibson's SQRL protocol in there. I'm an avid listener of his Security now podcast, and his protocol was the first decentralized passwordless protocol I heard about. It got me really excited.

I saw a mention of 2.0 working with desktop+mobile.

Will it be possible to designate a central device for 2FA? I imagine that all "slave" clients will somehow contact the "master" client so that you can authenticate there, or at least set up some sort of P2P replicated password vault?

Yo! The blog post mentions Linux support. The README's section on Linux is blank. Maybe I'm missing something. Is Linux actually supported (yet)?

cobased.com:

Under MacOS/Safari, with an installed SecureLogin app, and logged in. Whenever I click on "Change securelogin" and press cancel - and/or allow and later on close the securelogin app -, doing a reload pops up an empty message modal with a close button in the browser.

The SecureLogin vs X table says that with securelogin the cryptographic key never leaves the device. This is fine as long as the device can't be easily compromised.

Storing the key on a macbook pro or in a phone means it can be lifted and used to impersonate a user.

Hardware tokens such as the yubikey or smartcards in general may cost money (once) but the key can't be extracted (without expending considerable resources at least).

It would be nice to have the option of being able to use a hardware token provided key for the securelogin.

Nexus 6P:

visit cobased.com
click on secure login
click on cancel
redirected to securelogin.pw
click get it on google play
click on install
setup un/pass
click on change application square
System UI has stopped

go to settings
apps and programs
Settings app has stopped

only way to uninstall it is via the play store

Nexus 6P (not rooted)
Android 7.1.2
Kernel 3.10.73

For a number of reasons (primarily spam related), my email address is different for every single service that I use. Many people use plus-addressing for this purpose - I happen to own a domain and just use identifiers before the @. This protocol assumes that I want to share a single email with every service that uses it. Facebook login and other systems will give me an option to not provide an email. When that option is not there, I choose not to login with FB / Google.

Currently a private key is derived from the master password and then stored on the device in base64. From this point on, the master password is never needed. The saved profile is all that's needed to authenticate. At least on Windows, that can be a concern. Malware could read AppData and steal the key.

Could you provide an option to encrypt the private key and require the master password?
Or even not store the key at all. Realistic use case: one-off authentication on a friend's device.

Edit: as it stands, this is essentially like a global cookie: it's saved on the device, and if you steal it, you don't have the user's password but can still act on his behalf.

Hey @homakov,

We talked a bit through twitter yesterday and thought I might as well elaborate a bit more on some of my issues with the project. I'll post each of them separately so they can be fixed and tracked.

Separation of Concerns

Spec and Implementation

My most pressing point is the confusion between specification and implementation. You wrote a medium post about a protocol; but delivered a repo with an implementation. Adding to that confusion is the complete lack of structure within the example implementation.

If SecureLogin is a protocol; I would advice treating it as such and create a clear separation between specification and implementation. Spec should get a repo, and each implementation should get a repo. Changes and discussions to the protocol are relevant for everyone. But someone figuring out why Cordova 6.4 didn't compile doesn't interest someone who runs everything in GO.

Related to: #24, #34

Repo and Code

This brings me to my second point; presentation of implementation. In general it benefits everyone if code is consistently structured and follows common programming patterns. In case of a public repo it gets even more important to follow a consistent format.

First, please read up on the best practices for Cordova and Electron. How do you structure the base of your project? What are the distribution channels and how to correctly track dependencies? After that I'd suggest implementing something like Angular, React, Ember or Vue.js for your Cordova app. When you pick a framework, make sure you either follow best practices or document your own practices. This way people can navigate through your project without being familiar with it.

Put SL into modules

Like I said in spec; implementation must be strict but is irrelevant. It follows the same logic no matter what language you use. Because of this I would advice providing modules for popular languages which expose the SL api in the language of choice. If you maintain these modules you limit the effort required for implementing SL and also keep some control over the rollout of feature changes / bug fixes.

Of course each module should get its own repo with bug tracking, documentation and examples

Testing

Please write tests.. You're working on a serious project that requires 100% stability before anything is pushed to master. Imagine users losing the ability to login into existing websites, and at the same time registering new profiles with a wrongly determined password. You'll end up with a scenario where you can't roll back.

Have a nice day

https://www.dropbox.com/s/vb3zwsnb6gb2ejy/Screenshot%202017-11-04%2013.16.50.png?dl=0

may be Firefox 57 and above don't or won't support securelogin:// protocol. But then the README.md needs to be updated with supported FF versions.

The installer crashes all the time on my Samsung S6. Now what?

Deterministic keypair derivation: I get that the idea is to avoid having another file that you must keep secure, but it is well proven that passwords suck. You could have the same smooth integration with a truly random per-device private key. Can even reuse code from PGP and/or SSH keys.

Writing down password: https://securelogin.pw/ says "Make sure you write down your master password" - y'know, that thing that you are NEVER supposed to do. Why would you advocate this?

Plaintext private key: In issue #16, it was stated "Users are encouraged to use full disk encryption and a passcode on their devices. Apps are not responsible for this." - encouraging is not enough. We've been through this with FileZilla, who had to give in after 9 years: https://trac.filezilla-project.org/ticket/2935 - Encrypting the private key does help, as it prevents random malware from making use of the file while the filesystem is unlocked.

http://joxi.ru/52a1YDyT8o5O20

I uploaded your extension to the extension compatibility checker and it seems to work.

Please upload it to AMO as a zip. You can test it in about:debugging in Firefox.

Check out browser support and web-ext.

I'm really missing the flow diagram. Sharing a showing code examples is nice. So are animated gifs. But this repository is missing one key ingredient - how it works. This information should be right at the main page.

Here is example of a such diagram:

Currently, at the double check milestones (2, 4, 8, 16) the user is prompted to enter their password into a plain text JavaScript prompt. We need to find a better way to do this because we don't want the user entering their password in a plain, non obfuscated text field.

As discussed in #24, it seems you can claim additional security over traditional passwords only if the unique password is very strong. If the unique password is weak, my understanding is that your solution is weaker than traditional passwords (or maybe I'm wrong ?).

A solution: add strong conditions to the unique password. That would hit usability and adoption.

An other solution: add reasonable conditions to the unique password and ask user for one or several pieces of personal data ? (pet's name, etc.)

I'm fascinated by your claim that this is a simple, decentralized, software-only solution to the Authentication Problem that somehow you have solved where lots of other smart and highly-trained people have failed. You must forgive me if I'm a bit skeptical. I've seen your readme here, and your blog post, and you have given us a lot of bold claims, and some code, and a flow diagram. I don't feel like trying to read the code to decide if this is something real or not. The flow diagram is a good, but unclear and insufficient. What you need is a detailed explanation, in clear English, of what is going on in that flow diagram. Something that I, or even better, a crypto/security specialist, can read to determine if your solution is worth spending time on, or if it perhaps has a fatal flaw. I look forward to reading your protocol description.

Being a SecureLogin site expired SSL cert sure doesn't look good. A permanent solution to this problem would be to automate the SSL cert renewal using any of these clients https://letsencrypt.org/docs/client-options/

MacOS client gives the message:

"You don't have SecureLogin profiles. "

Then nothing happens :O. What I'm doing wrong?

I just dl'ed the client, installed it, then tried the demo page, but gives the same message every time. The web based client works.

I could start offer some help with the NodeJS implementation in about a week from now. Is there any known implementation already or has anyone started to work on it?

I've installed the native app and here is what I get when using the demo to send $123 to "aaa":

Another reason to switch to Universal links. Those are seamless (no confirmation to open) and open in private mode too. Priority task.

For working offline we will add appcache manifest.

ok

Hi Egor,
Been seeing a few issues posted here that parallel one concern I was putting into my general analysis, so I thought it better to post it here for clarification rather than leave it until later.

It appears from reading through the code (there really should be a written spec) that the SecureLogin authentication scheme uses an Ed25519 asymmetric key pair to perform a Zero Knowledge authentication by deed of signing a random challenge. It does this by having a user generate a single authentication key pair for all sites via a deterministic hash function that takes as input a provided email address and passphrase. This hash is then used as the feed to generate signing keys for a given challenge.

Issue 1
Having only deterministic inputs to generate signing keys degrades them for their use in Zero Knowledge Proof (ZKP). This is because the root of ZKP is that given perfect knowledge of everything that passes it should be infeasible for an attacker to generate their own proof to any given random challenge.

But, in SecureLogin the 'email' parameter & public key is passed for storage on the server side leaving only the passphrase as an unknown. This reduces the entropy of generated keys to that of the passphrase and thus leaks knowledge of that in the reverse direction making the protocol no longer a ZKP. The task then of finding the private key from captured/exfiltrated data is one of guessing passwords and running the known key generation algorithm to produce public keys for comparison.

This then makes SecureLogin potentially as weak as any traditional stored password hash systems that uses an equivalently strong salted password key derivation function.

Solution
It is my belief that signing keys must be generated from an entropy source of equivalent or better strength to the keys being generated. That unfortunately precludes direct password to key generation but does allow randomly generated keys to be encrypted and stored local to the client under a reproducible static key or secured in dedicated hardware where only the results of an inputted signing operation can be accessed.

Other issues will be posted separately

In the developer tools I always see problems with /s or /s.js . In Chrome the problem is (failed) "ERR_FAILED", and on Firefox it's just stuck, never loading.

When I open /s separately, it works. But on the demo pages the above behaviour is observed.

Correct me if I'm wrong, but there doesn't appear to be any verification of the email provided to the server.

The demo code seems to imply that we can trust the email address provided by the client:

If the user with given pubkey does not exist, simply create a new account with given email.

But the user can enter anything they want into the email field of the app. I signed up for the demo app with [email protected] for example. It seems confusing to imply that the users's account can be associated with the email they provide without some kind of independent verification, and if you're verifying emails then why did we bother with all the public-key stuff?

I would think it would be better to say that each users's account is tied to a fingerprint of their public key, since that's the only thing you can guarantee ownership of with this system.

It might be worth having fields like "email","requested_displayname", or "sms_number" that the server can use to pre-fill their account with contact information and such, but it should be made clear that the provided values are advisory only and must be verified before being used. Especially because I think it's against the law in a lot of places to send emails or sms messages without the receiver's consent.

The "Legacy Password Generator" just makes SecureLogin even more difficult to understand. Is it really useful?

My understanding is that user email serves no purpose in your system. Why not removing it?
Asking for user email has the following drawbacks:

• More complex UI
• End users will think you'll use their email for some dark purpose
• Cryptographic expert will say that using a piece of public data to generate a secret is a weak spot

I know you use the email as a profile name. See below.

Understanding what "profile" is about is difficult. It is just a character string to identify the active password, isn't it? I suggest you:

• Forget about the term "profile"
• Replace it by the notion of "active password" and "password label"

1. Move enrollment from securelogin.pw to modal iframe, i.e. no 3rd party windows

2. replace confirm() with HTML modal window