3 ms·

It's a powerful idea but say I'm a website that wants to add "Sign In With HN". Me personally I've lost faith with "Sign In With Facebook/Google/etc.", nevermin

It's a powerful idea but say I'm a website that wants to add "Sign In With HN". Me personally I've lost faith with "Sign In With Facebook/Google/etc.", nevermind some random site offering sign ins with random forum identities. As a website owner, I would have to trust that the "Sign In With HN" service would still be there in a month or two, nevermind a year or two. If I wanted to create such an SSO service, what kind of reasonable social/technical guarantees could I make to website owners so they'd be confident I'd be around for the long haul? A better technical solution would be to offer an SDK that does the same thing that websites could integrate themselves, but then you have the explosion of languages and frameworks to support.

motohagiography 5y ago
This is the good part. I'd rather avoid the SDK case, as I've run down that road before and it's fraught. If you affinity federate to HN, (or even a subreddit), and you create a recovery process that enables the user to migrate their local identity on our app to a new IDP, realistically, you could just federate to anything someone can store a key on, if you wanted to. The security of the users account is up to the user. If I want to bind my user account on your SaaS app to anything persistent online that I have control of, that should be sufficient for most low assurance purposes. The lightweight security of it is that if I enroll/register for your app as motohagio@location.public_key, my password for your site becomes just a random string encrypted with my private key, as that proves my possession of the private complement used for registration when you decrypt the string using the contents of the public key location I provided during enrollment. A lot of protocols already essentially look something like this, they're just not described in a casual comment. The lightweight security of the system isn't based on the secrecy of passwords, but rather, a combination of the secrecy of the users private key and the integrity of the registration pointer to that public key. It still works with browser passwords, as instead of a password string, you submit {randomstring, (randomstring)^privkey_privkey} and the RP app just looks up its registered public key pointer, and makes sure the random string in the ciphertext matches. Problem it solves is net-net it shifts risk off your service, onto the user, and removes a single point of user compromise for all users at once. You can federate your service to any document on the internet that persists a public key, and account compromises don't scale the same way. The most obvious vulnerability is the integrity and availability of the location and directory services of that public key location. But cacheing and recovery schemes could make it viable. (some people will be apopleptic at the mere mention of it, but it's a use case for the chains made of block) I've done the high assurance use case design on a variety of other products, but maybe the low assurance case is the one that's actually useful. Irony is it may still require a password manager / authenticator client for most users, but in the majority of logins, you can still save this new token in your browser as a password.

motohagiography 5y ago

This is the good part. I'd rather avoid the SDK case, as I've run down that road before and it's fraught. If you affinity federate to HN, (or even a subreddit), and you create a recovery process that enables the user to migrate their local identity on our app to a new IDP, realistically, you could just federate to anything someone can store a key on, if you wanted to. The security of the users account is up to the user. If I want to bind my user account on your SaaS app to anything persistent online that I have control of, that should be sufficient for most low assurance purposes. The lightweight security of it is that if I enroll/register for your app as motohagio@location.public_key, my password for your site becomes just a random string encrypted with my private key, as that proves my possession of the private complement used for registration when you decrypt the string using the contents of the public key location I provided during enrollment. A lot of protocols already essentially look something like this, they're just not described in a casual comment. The lightweight security of the system isn't based on the secrecy of passwords, but rather, a combination of the secrecy of the users private key and the integrity of the registration pointer to that public key. It still works with browser passwords, as instead of a password string, you submit {randomstring, (randomstring)^privkey_privkey} and the RP app just looks up its registered public key pointer, and makes sure the random string in the ciphertext matches. Problem it solves is net-net it shifts risk off your service, onto the user, and removes a single point of user compromise for all users at once. You can federate your service to any document on the internet that persists a public key, and account compromises don't scale the same way. The most obvious vulnerability is the integrity and availability of the location and directory services of that public key location. But cacheing and recovery schemes could make it viable. (some people will be apopleptic at the mere mention of it, but it's a use case for the chains made of block) I've done the high assurance use case design on a variety of other products, but maybe the low assurance case is the one that's actually useful. Irony is it may still require a password manager / authenticator client for most users, but in the majority of logins, you can still save this new token in your browser as a password.