What, generalising the idea to be more widely applicable? Sounds like fun.
For reliability, you'd probably want to switch away from my simple one-time-pad mechanism to something more like a threshold scheme: cache (say) ten password fragments on independent servers, and arrange that (say) any five can reconstruct the password but any four give no information about it. That way you're protected against a few of the servers being down or unreachable at any given moment, which is probably helpful in practical terms.
Querying the servers using (securely authenticated) UDP is probably a good plan too; if you only need half of them to respond, then reliable delivery doesn't matter to you all that much, and it means it's very easy to send out ten requests and then wait until you've got five responses back, thus taking only one RTT for the entire process (unless you only get four responses and have to re-send, but that'll be uncommon). Much faster than TCP, and orders of magnitude faster than SSH!
The interesting question is whether anyone could run a public service doing this sort of thing. Technically it's all easy enough on the server side (though funnelling the reconstituted password into custom weird-ass client software will always be a painful client-side headache): a bunch of independent organisations each run one server, and a user picks ten of them and uploads a password fragment to each. But the trust issues are the fun bit: how does the sysadmin of each server assure its users that it's genuinely independent of the others, and isn't colluding with them to reconstruct a whole lot of users' passwords?
Perhaps the answer there is for the client to hold the final vital piece of the password. (In fact that ought to be a genuinely vital component, not just another cog in the threshold scheme; perhaps it's the one-time pad that decodes the final output from the threshold scheme.) Then even if all the server admins colluded, they couldn't reconstruct your password between them. (They could collude to create trust paths between their servers, which would reduce the difficulty of an attacker collecting all your pw fragments, but this wouldn't be of direct benefit to the admins themselves so there'd be no incentive for them to do so. I think.)
This is starting to sound disturbingly plausible, in fact! I've almost convinced myself it's a viable business opportunity. I expect it would only be of interest to a few hyper-paranoid security geeks like me, though, so there wouldn't actually be any profit in it :-)
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
For reliability, you'd probably want to switch away from my simple one-time-pad mechanism to something more like a threshold scheme: cache (say) ten password fragments on independent servers, and arrange that (say) any five can reconstruct the password but any four give no information about it. That way you're protected against a few of the servers being down or unreachable at any given moment, which is probably helpful in practical terms.
Querying the servers using (securely authenticated) UDP is probably a good plan too; if you only need half of them to respond, then reliable delivery doesn't matter to you all that much, and it means it's very easy to send out ten requests and then wait until you've got five responses back, thus taking only one RTT for the entire process (unless you only get four responses and have to re-send, but that'll be uncommon). Much faster than TCP, and orders of magnitude faster than SSH!
The interesting question is whether anyone could run a public service doing this sort of thing. Technically it's all easy enough on the server side (though funnelling the reconstituted password into custom weird-ass client software will always be a painful client-side headache): a bunch of independent organisations each run one server, and a user picks ten of them and uploads a password fragment to each. But the trust issues are the fun bit: how does the sysadmin of each server assure its users that it's genuinely independent of the others, and isn't colluding with them to reconstruct a whole lot of users' passwords?
Perhaps the answer there is for the client to hold the final vital piece of the password. (In fact that ought to be a genuinely vital component, not just another cog in the threshold scheme; perhaps it's the one-time pad that decodes the final output from the threshold scheme.) Then even if all the server admins colluded, they couldn't reconstruct your password between them. (They could collude to create trust paths between their servers, which would reduce the difficulty of an attacker collecting all your pw fragments, but this wouldn't be of direct benefit to the admins themselves so there'd be no incentive for them to do so. I think.)
This is starting to sound disturbingly plausible, in fact! I've almost convinced myself it's a viable business opportunity. I expect it would only be of interest to a few hyper-paranoid security geeks like me, though, so there wouldn't actually be any profit in it :-)