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 https://github.com/sakurity/securelogin/issues/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.

[ramriot]

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

Unfortunately a public key can only be truly treated as such if there is no weaker method of deriving the commensurate private key. Your proposal definitely provides that by deterministically deriving the key-pair from a much lower entropy source, even if there is a high work-factor KDF involved.

If you wish an example of crime made possible by such a weakness look up Deterministic Bitcoin Wallets etc. These keys with better high-entropy keys appear in the blockchain, where eager attackers are free to use their spare computing capacity to brute force the potentially weak root passphrases, which does happen.

you need to take into account a natural disaster.

Agreed, but that could also be the loss of the user due to death or incapacity, what of that. The traditional requirement that is a proper securely administered backup of some kind so that your inheritance can be assured. Well if you need such a backup already then we don't need to weaken security by using deterministic keys.

In closing, I think such better 1st factors are where we need to be going. Unfortunately I see no viable means for gaining convenience without losing some security, especially when it comes to deterministic keys based upon memorable input. Thus then because we should not weaken encryption to really make a dent in the world of authentication someone needs to devise a secure & scalable means of credential backup.

[steph643]

Thus then because we should not weaken encryption to really make a dent in the world of authentication someone needs to devise a secure & scalable means of credential backup.

That's what the cryptography community has said for 25 years. And average users are still left alone with weak passwords for their accounts and nothing practical to protect their privacy. I'm glad you didn't "weaken encryption". But to the cryptography community as a whole I say: you failed us. It's time a new generation accepts to get his hands dirty and design suboptimal but practical solutions.

[deltaidea]

I agree with the sentiment from @steph643, but I'm not sure if there's any practical value in this solution.

Users use weak passwords. Users use the same password for many things. The core question is what's better (harder to break?):

• traditional centralized databases with hashed credentials, where the weak link is the service with worst security,
• or a public key that anyone can bruteforce with gazillion attempts without trace, at 2 seconds per iteration on a decent machine.

I have no idea what the answer is, and I feel like it's different for different users.

[andrewda]

@deltaidea We can't assume that all websites hash users' credentials, though. Sure, it's strongly recommended and crazy not to, but I've gotten my fair share of emails with my password in plain text from poorly programmed websites. It goes without saying that that's the weak link. Considering that the typical user doesn't usually think twice about creating an account with a reused password, it just takes one rogue employee at said website to steal hundreds or thousands of credentials, many of which are probably the same as the user's email password.

[homakov]

If you wish an example of crime made possible by such a weakness look up Deterministic Bitcoin Wallets etc.

Brainwallets are amazing if done right. Separate post to distinguish bad from good ones https://medium.com/@homakov/why-brainwallet-are-great-for-cryptocurrency-ff73dd65ecd9

"high work factor KDF" is not just a minor handicap for the attacker. Making an attack N times more expensive ~= getting N less hacks. I do actually plan to take random pw from top 10M, put some BTC in it and make a bug bounty. WarpWallet did it before. If this monetary challenge doesn't prove this approach is viable to you, what else would?

Great sentiment @steph643 - so many years passed yet no single move in (right) direction. U2F/SSO-ing through central authorities/one time codes to type from a phone - all that just looks ridiculous. (SQRL is pretty good, but I have few key objectives about key storage and camera requirement, hence working on SL instead)

Thus then because we should not weaken encryption to really make a dent in the world of authentication someone needs to devise a secure & scalable means of credential backup.

IPFS and other decentralized file system look very promising but you need a private key to join them.

@deltaidea if we assume the public key is private, then it's the same as traditional option - as long as no one leaked your public key, no one can start bruteforcing it. So it's an instant win for #2 option - at least one leaked pubkey is a prerequisite to offline bruteforce. And local scrypt is by definition stronger than anything the server can do for you (they don't want to DoS themselves)

Like I said, it cannot get any worse than it is now. Any action is an improvement. Even login link by email (removes reuse problem, leaves reset problem). Maybe only SMS on phone number (see: digits.com) the only worse way to implement auth.

[ramriot]

(SQRL is pretty good, but I have few key objectives about key storage and camera requirement, hence working on SL instead)

Fear not, there is and never was a hard requirement for a camera in the protocol. That use case was for either separate device authentication (now deprecated as a far less secure method) or for optical import of credential files (only ever an optional import mode)

[homakov]

I see, then you should also drop QR part of the name, a bit frustrating. Anyway, it's just different vision, also better than what we have now.

[ramriot]

I would agree, unfortunately we are quite enamored of the acronym SQRL - pronounced Squirrel. Which was b-acronymed to Secure Quick Reliable Login and has a paid for logo.

In any case the idea is that SQRL login pages will display a login QR code with possibly embedded logo as a clickable image on the page. That way Click or Tap will initiate the much more secure same-device authentication protocol (with phishing protection) while still allowing Snapping of the image via the client on a separate-device to initiate the still good but lacking Phishing protections separate-device login.

The separate-device method in any case will have a future use case in places where either the e2e display can be trusted, or where the realm of authentication is not a web-session i.e. POS, voting, physical-access etc. Its also quite useful in those cases where you don't want or cannot put the client on the same device but still need to authenticate something i.e. Untrusted devices.

[homakov]

I understand why - I also want to put QR back for doublesign or untrusted devices, but at this step with low adaption, imo no need to bloat software with pretty big qr libs when most of the issue is about same device auth.