urbit
Deterministic Password Manager integration
Please excuse me putting this here, but right now my planet is disconnected again, fora is down, reddit is obsolete, and there's basically no public place to discuss urbit ideas.
Anyway,
I was reviewing stuff like SuperGenPass, LessPass, Master Password (deterministic password managers), and it occurred to me that Urbit could be really useful for making these mechanism much more secure.
To recap, deterministic password manager takes (domain, master password, potentially other stuff) and generates per-website passwords. The biggest weakness of this approach is - in case the master password is compromised, all passwords derived from it are.
It seems to me it would be fairly easy to supplement this approach with Urbit, to eliminate the weakest point.
A deterministic password manager would do what it normally does, and in addition, it would request additional password from urbit: be sending it the same (domain and potentially other stuff) to https://ship-name.urbit.org/ and receiving in response additional deterministic entropy, derived from a different master password, stored on Urbit. These two can be simply combined (concat + sha256 or whatever).
In addition urbit could store some stateful information like password counter, password contrains (which alphabet to use), etc.
This approach makes it so attacker would have to obtain both master keys: the one provided by the user and the one stored on urbit.
Each app would authenticate with urbit through some +code-like mechanism, and rate-limiting could be implemented. Once Urbit runs moons on mobile phones, it could be used for asking user to confirm each password request.
The beauty of this approach is, that "urbit salt" could be easily implemented as an additional feature/fork of popular password managers (LessPass, Master Password), so a lot of UI work would be already done.
And as urbit can already do basic crypto, I believe the urbit side of this would be straighforward.
@dpc we're designing a new proposal system at the moment. I'll make sure this ends up there.
We've kicked this idea around a bit (a long time ago). It's nice to think about — but I'd be scared to have people putting secrets into Arvo without a real audit. And that's quite a challenging task.
I wouldn't be averse to seeing work on the application logic / interface. So long as it comes with lots of Big Red Warnings about Do Not Use This For Real etc.
I like this proposal because compromising arvo would only reduce the security to the level of the existing best practices.
I like this proposal because compromising arvo would only reduce the security to the level of the existing best practices.
Exactly. As long as it's being used to supplement an otherwise entirely local password generation, Urbit works just as a 2nd factor. If it gets compromised, the user just reverts to security provided by deterministic password generator.
I was thinking that I would like to use deterministic password manager, but by itself it has weaknesses. I'd like 2nd factor on that. But I need something that is publicly reachable and reasonably secure. And if it's 3rd party then I compromise on privacy. So I would like to run it myself. That might work for me, because I am skilled Unix professional, but not for "normal users". So then I'm thinking ... what is supposed to be privately owned, maintenance free, can have a built-in human interface, can do crypto and is publicly reachable? Urbit. This is exactly the sort of application that fits "small notebook for your small data". And something people would be compelled to try, pay $10 for an account etc. Just for this single app! If it's easy enough.
Okay, yeah, now I get it. I didn't understand you correctly the first time around. In your scheme, Urbit is just providing the convenience of hosting the encrypted data.
This isn't that hard to do. And I agree it'd be nice to have an open source alternative to 1PW, LastPass and so on.
There's a lot of usability benefit from the 1PW UI, though. The keyboard shortcuts, auto password generation and so on.
Urbit would not just "host the encrypted data". It would actually generate on-demand site-specific password (or rather deterministic entropy), derived from the master-password it stores. But it would be second factor entropy. The first entropy, would be entirely user-browser-side, just like it is now in solutions like LessPass or SuperGenPass. These two entropies together give the final entropy - actual site-specific password derived from both Urbit-side-master-password and browser-side-master-password.
This way even totally compromised Urbit reverts the user to a standard security provided normally by LessPass or SuperGenPass. But the improvement is: if browser-side is compromised, and browser-side master password is stolen, the attacker has to query Urbit for every the second factor entropy for every site. Which can be rate-limited, or even require user to click OK on the moon running on a phone or something like this. Also user will have easier time rotating passwords, if Urbit is used to store per-site counters, etc.