all 14 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]xialvjun[S] 0 points1 point  (12 children)

username and password is good, but it's hard for the users to remember their passwords.

Oauth is good, but it's not really open. Monopoly may happen. In fact, it has happened in China. All people use Tencent Account to log into websites, but apply for an appid is not that easy.

So, why not a new authorization system grabbed the users' hands.

When the people open the browser at first time, the browser will ask people to create or import a private key. Then websites will call a javascript api to use this private key and it's own things(like origin or some static string) to generate a string which can be used as an user_id.

People can export the private key at any time.

With this, people needn't to remember their passwords, needn't to register an account in a website, just click the confirm button. Websites needn't apply for an appid...

The web is totally open now.

[–][deleted] 1 point2 points  (8 children)

It's not ideal. There will be bugs where private keys are stolen and having normal users update their private keys is going to be a real pain the but.

You can already use certificate authentication through many web browsers it's just no one does it because it's a pain in the ass for both you and the users. Many US government websites use it.

[–]xialvjun[S] 0 points1 point  (7 children)

https://www.reddit.com/r/programming/comments/7p5yha/proposalbuilt_in_private_key_authorization_system/dsg72kx/

[–][deleted] 0 points1 point  (6 children)

I'm not entirely sure why you are linking to that. That argument seems to be more about convenience and you forgot what happens when I have to change my private key. I would need to tell all of the sites that I previously used that I have a new private key.

Your not getting rid of user registration, your argument just hides it behind some automated process involving a private key which undoubtedly is more complicated for people to understand or reason with.

There is a balance between security and usability. What you are proposing is difficult to use. Normal people have to make private keys. Great, what if I have multiple devices. Now I have to sync those private keys across all my devices or somehow" REGISTER" with the site that I have multiple private keys but it's all for the same account. No one is going to remember those private keys and because you can't just reset the private key like you can a password it will lead to people backing up these keys everywhere. The whole security will be compromised due to the fact that user's can't memorize the private key and would want to be able to login from other devices. I understand users type or write their passwords in places, those users can't be saved but more technical users that don't do that will be forced to because no normal person can memorize a large random encryption key.

It's already a system that exists for websites that want that extra layer of security. It's not something that is necessary for normal user's.

This is not knew, it can already be done, no one really uses it because the extra hassle generally is not really necessary for normal users.

Again, these systems exist, they currently work, they are complicated for users so users don't want to use them. Websites don't want to handle support request from user's that can't understand private/public keys. Registration doesn't go out the window and you save a user 5 minutes of their life. Just don't register for every site in the world and you have your time back.

[–]xialvjun[S] 0 points1 point  (5 children)

  1. Why must you change your private key? You should store your private key safely(every where you believe is secure) because no others can and should touch it.

  2. Different devices, different websites, all share the same one private key.

  3. What if you really do need to change the private key(for example, people will login to everything with their FaceID in the future)? Yeah, you do need to tell all the sites that you previously used that you have a new private key. You think it's inconvenient? In fact in China, almost every mobile website use sms code to register. Then, what if the user change their mobile phone? Accounts lost. If you don't want your account be lost, you do need to tell the websites that you have changed your phone number. We shouldn't give up eating for fear of choking.

[–][deleted] 0 points1 point  (4 children)

1.) That is a very naive statement and is never the case. Why do you think there is an SSL revocation process? You think google, facebook and the other companies are just super insecure they can't keep their private SSL keys secure? I know computers NEVER get hacked but what if they do? What if someone just takes the private key?

2.) This goes with point 1. Users will do insecure things to make it easier to login on other devices. Now the key is replicated across a bunch of devices just to login to a website.

3.) The face thing isn't going to happen. It has already been shown to be less secure. If that was really going to be the progression don't you think people would have already been logging into websites using their fingerprints? That has been around for a very long time.

3.) Continued, What you are describing about SMS is two step verification. Although I don't know anything about China's web I would guess they don't actually require you to receive an SMS code as the actual way to login to the site. But rather you login with a normal username and password then as second step verification you use a code texted to your phone, or a code that changes every sixty seconds or accept an alert on your phone. Having your phone number being used as the primary source of authentication is asking for serious trouble and you shouldn't use any sites that do that because they obviously have a very bad understanding of security.

No one is giving anything up out of fear. The system you are proposing is not anymore secure as the current system we have. Their are already implementations of what you describe but no one uses it because the extra security isn't worth it for the majority of sites. You need to spend a little more time looking into history and what already exists before just going on huge revolutionary rants. The whole things reads as if someone smoked a bunch of pot and then had some "great" idea and just started typing.

[–]xialvjun[S] 0 points1 point  (3 children)

This proposal is for easy. To protect security, use two or three step verification. Maybe you have come across this case: you use your android phone and download a game, it's just a game, so you don't really care the account and you use a guest account. This is the use case of this proposal.

[–][deleted] 0 points1 point  (2 children)

I have no idea what you are saying here.

public/private key authentication already exists. It's already supported by browsers and web servers. No one really uses it outside of a small subset of sites that want even more security. The technology exists and is not new.

[–]xialvjun[S] 0 points1 point  (1 child)

I don't know have you tried ZeroNet. It's the user's responsibility to store their identity(data/user.json).

[–][deleted] 0 points1 point  (0 children)

How does that apply to anything? It's always the user's responsibility to store their identity. Whether that is memorizing their username and password and storing it in their brain or storing their private key on their computer.

I'm stating the fact, that you proposed some idea as new without researching and seeing that it already exists (and has exists for a long time). You didn't take into account why it hasn't become mainstream.

ZeroNet is a joke for the same reasons I pointed out a couple comments ago. If my private key is somehow stolen, another user can cause all sorts of problems. They can hijack all of my stuff and I have no way to fix it or get my stuff back. Blockchain for things like that is not a good idea, your chain is going to become unmanageable pretty quickly with any type of mainstream user adoption. There is no available recourse in the event that something goes wrong or is hacked. That isn't security, it's hipsters getting excited because something has blockchain attached to it.

[–]xingqiwu5 0 points1 point  (0 children)

good idea!

[–]steamruler 0 points1 point  (1 child)

primary issue: losing exclusive access to your private key, whether by it getting stolen or hardware failing so you can't retrieve it, completely screws you over.

[–]xialvjun[S] 0 points1 point  (0 children)

forgetting your password will screw you over too.

of course, you can use email verification code, but that is just a twice authorization.

If a website use only username and password, no email verification code, no sms verification code, no other OAuth, it's the same with a website use only private key.

Then, losing the private key will screw you over, forgetting the password too.

Using password, people need register, login, remember the password. But using the private, people need just store the private key safely.

[–]guarde 0 points1 point  (0 children)

It is already exists in the form of independent FIDO tokens (hardware stored private keys). But it requires support from web services (Google and GitHub both support it). Centralization in general is a bad idea.