Need clear explanation

[kotodharma]

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.

[homakov]

Missed this issue @kotodharma
can you look at https://sakurity.github.io/securelogin-spec/index.html is it close enough?

[steph643]

What seems to be missing is a short description of when and where my private key is generated, where it is stored, how I can transfer it among my devices, and what happens if it is accidentally deleted.
Or maybe I'm completely missing the point?
There are a lot of cryptographic schemes flying around and few people can invest the necessary time to understand them all. I think you need to build a concise technical case.

[homakov]

Pretty much every post about SL mentions it is deterministic KDF, i.e. private key is generated from scrypt(email, pw), to recover/transfer you just use the same inputs, and there's nothing to store.

[steph643]

I haven't seen that when doing a quick scan of your articles. It means either:

1. I'm stupid
2. I'm lazy
3. I'm not in your target audience
4. Your communication has issues

You'll decide which option is the right one, but please charitably accept that I comment on hypothesis 4.

I was annoyed by the fact that you start with your product's features and benefits (decentralization, usability, etc.), and then, for each benefit, explain how your cryptographic scheme allows for it. This forces the reader to re-compose the cryptographic scheme from partial elements, which is hard. More generally, when you mix benefits with technical considerations, I think you alienate technical people. They tend to feel that you're trying to hide the weaknesses of your system behind a "marketing" speech.

I think you should clearly separate:

• A white paper which would start with how your cryptographic scheme works. It would contain a detailed flow diagram that alone would explain it all. It could end with some short considerations about features/benefits that are permitted by the scheme (decentralization, usability, etc.).
• The presentation of your product's features and benefits, without any technical or implementation considerations.
• Technical documentation about implementation, installation/deployment...
• Your demo, accompanied with an explanation about who it is for and what it demonstrates

Then, in any blog post you publish, you should refer to this place where I can find those separated elements. This would allow me to stop reading the blog post, go directly to the white paper and implementation details, then maybe come back to the post.

[ethernal]

As far as I understand that you don't store password as EVERY TIME email and password combination will generate same AUTH token.
That means it's prone to brute force attacks / pregenerating a hash table for emails and passwords etc.

I hope I am wrong here.

[homakov]

Everything is prone to bruteforce at some extent. Some creds are hidden behind central authorities and have rate limiting, but it is even worse.

We use sufficiently strong derivation to make bruteforce threat irrelevant.

[ethernal]

Just a sec.. am I right or wrong here. There is either really serious communication issue or serious security issue with this "protocol".

I am no expert but if it is possible to get this app/protocol and generate huge number of email/user and password pairs that are ALWAYS deterministic then this is a joke not a secure way to communicate my credentials.

Please, please explain how are passwords generated.

To illustrate my point better here's an example:

in any (maybe not all?) programming languages when you generate a pseudorandom numbers you can add a "seed" number. If that seed is known you will ALWAYS be able to generate the exact same array of numbers. BTW. this is how River Ride game levels were "procedurally" generated some 25-30 years ago.

Back to the topic - if this is the case and user never submits personal "seed" number (as seems to be the case) anyone should be able to generate the pair with my email and any password combination that will ultimately work, but I can't seriously believe this is the case.

Please could you explain it better?

[homakov]

All user supplies is email and pw, which are used as scrypt(email+pw). No other seed is used.

The attacker may test a lot of email+pw combinations but given derivation scheme used it will cost more that the bounty expected.

ALWAYS deterministic then this is a joke not a secure way to communicate my credentials.

Not really. How about I put 10 BTC in a SL protected wallet and you try to guess my human-generated pw? Check out this thread #34

[ramriot]

Hi @homakov,

Unfortunately its not your choice of PW that concerns me & possibly @ethernal, it is the average user who we all know is notoriously bad at doing this.

The root issue here is that if this protocol is explained clearly it becomes obvious that it is in effect a password KDF by proxy & does not clearly devolve secret keeping to the user alone, leaving them with a false sense of security & allowing them to choose weak passwords.

It also has the catastrophic deficit that it currently forces same key use everywhere. Even if as you have suggested previously the KDF can take in the additional argument of a sites FQDN, that is still a known element and so a brute force knowing a leaked 'Public' key can find a collision with high probability of this being the users master password to ALL their sites globally.

You may repeatedly claim that sCrypt adds sufficient strength to overcome this deficit but, because the very strong Public keys are centralised & deterministically linked to a users much lower strength password & site breach will leak all keys and allow an attacker the pleasure of picking off weak passwords in bulk.

[steph643]

@ramriot:

allowing them to choose weak passwords

What if the system doesn't allow for weak passwords? A unique strong password is better than many weak passwords, isn't it?

I understand your point, but I'm a bit uncomfortable. Yes, passwords are bad, but we know private key generation, storage and backup is not practical for end users. So where does this leave us?

[homakov]

site breach will leak all keys and allow an attacker the pleasure of picking off weak passwords in bulk.

Once again: site breach is not an "if", public key is public from day 1.

Current ecosystem relies on a vermicelli of recovery providers, email resets and so on. When you work on a system that has no recovery option (like yours and ours), you need to take into account a natural disaster. If a so called computer generated seed is stored on your systems server how do you guarantee a lighting won't destroy all backups? Or 2 lightnings at the same time? Or government making you to limit access to some of the seeds?

That's what I told in previous thread - rate limiting (and beware, no rate limiting is perfect) that trusted 3rd parties can provide is not worth the risk of them ransoming all users or just losing their database in my opinion. Maybe you are capable of building a server that is unseizable by authorities, natural disasters or hackers... then please run a currency on it because I'm tired of paying Bitcoin fees :)

Have a look at blockchains, the only reason they are gaining massive value is decentralization. People realize that it's the only way to truly own money.

SecureLogin approach is the only way to truly own your identity: as long as you have a CPU, email, pw, and an implementation of scrypt. Another benefit, it's also free.

[homakov]

@steph643

Theirs (SQRL) approach as far as I understand is:

The Identity Master Key is always stored in encrypted form under the user's chosen (and readily changeable) authentication password. This is the password they use to prove their identity to the SQRL client in their smartphone, laptop or desktop. It may be readily exported from the client for cloning to another device, or for backup storage.

https://www.grc.com/sqrl/key-flow.htm

I.e. it's on the user how and where to store identity unlock key. As a user, I wouldn't be excited to store and care about yet another credential file.

[steph643]

As a user, I wouldn't be excited to store and care about yet another credential file.

I'm 100% with you on this.