undefined | Better HN

0 pointskennywinker7mo ago0 comments

Sorry, are you expecting some way to authenticate without any secrets?

Could you describe how that would work? If two people have the same info, how on earth do you tell which is which?

The post is talking about simplifying things by eliminating all the back and forth. It’s not pretending to invent a secret-less auth system.

0 comments

deathanatos7mo ago

> Sorry, are you expecting some way to authenticate without any secrets?

I'm not. "It’s truly wild to me what some of y’all will tolerate." What, exactly, are we tolerating that is solved by asymmetric key pairs?

> The post is talking about simplifying things by eliminating all the back and forth. It’s not pretending to invent a secret-less auth system.

Well, then, I'm lost. What back & forth was eliminated?

In one system, we download an API key. In this system, we upload a public key. In both, we have a transfer; the direction doesn't really matter. Someone has to generate some secret somewhere, and bind it to the identity, which is what I was saying above, and is apparently the wildness that I'm tolerating.

actinium2267mo ago

Yes but when you have to do this 13 times, it gets really annoying to manage all those API keys. Especially if you need them in different processing contexts. If I could just have a single public/private key pair for my app it would simplify managing all the extra services I use.

deathanatos7mo ago

Thank you! I suppose yes, that it would amortize a few steps. (But as I mention in another comment, that only amortizes the management of the secret portions, which is a small portion of the objected to "insanity".)

kennywinkerOP7mo ago

> Visit our website. Create an account. Verify your email. Create a project. Add your credit card. Go to settings. Create an API key. Add it to your password manager. Drop it in your .env file. Download our SDK. Import it. Pass your env var in.

This is the pitch. But it seems like you fixated on the next part of the paragraph where it talks about api keys in version control.

I’ll agree with you in as much as this isn’t a massive change - but i like the approach for being an incremental improvement - and for challenging the status quo

deathanatos7mo ago

My point is you're still doing all that.

Let's say instead of downloading API keys, everyone on the Internet permits uploading a public key to represent a service. Now it's: Visit our website. Create an account. Verify your email. Create a project. Add your credit card. Go to settings. Upload an API pubkey. Download our SDK. Import it.

All of that seems unchanged by using a pubkey to represent programmatic access.

(And as a sibling comment more constructively notes, you might be able to combine pubkeys, so, "Add it to your password manager. Drop it in your .env file. […] Pass your env var in.", but potentially only once. So we can omit that part here, I suppose.)

j / k navigate · click thread line to collapse

0 comments

deathanatos7mo ago

> Sorry, are you expecting some way to authenticate without any secrets?

I'm not. "It’s truly wild to me what some of y’all will tolerate." What, exactly, are we tolerating that is solved by asymmetric key pairs?

> The post is talking about simplifying things by eliminating all the back and forth. It’s not pretending to invent a secret-less auth system.

Well, then, I'm lost. What back & forth was eliminated?

actinium2267mo ago

deathanatos7mo ago

kennywinkerOP7mo ago

This is the pitch. But it seems like you fixated on the next part of the paragraph where it talks about api keys in version control.

I’ll agree with you in as much as this isn’t a massive change - but i like the approach for being an incremental improvement - and for challenging the status quo

deathanatos7mo ago

My point is you're still doing all that.

All of that seems unchanged by using a pubkey to represent programmatic access.

j / k navigate · click thread line to collapse