Instead of trusting a third party to protect your credentials, you're trusting an auditable, open source platform. I cant see myself using it for anything important, but I understand the draw.
Any password manager that does the encryption stuff in offline, open-source software and puts it on any untrusted storage provides that, with the difference that it does not require making your encrypted copy public for all eternity, exposing it to unnecessary risk of compromise down the road.
There are risks either way. There have been plenty of vulnerabilities in popular password managers (some that also apply to this blockchain model). But I think your AES encrypted password being publically visible is a pretty low risk, compared to a PW manager being breached, having a flaw in the client, their being coerced by government, etc
How is this project any less at risk for those client-side implementation risks you mention? Basically, why should this nascent project be trusted over, say, KeePass?
Many password managers require you to have an account online, to store the password vault. Passwords don't take up much space, so instead of uploading your encrypted password vault to google drive or some other service, where google might decide to lock you out or stop maintaining the service, you can put it on the ledger.
When you need the passwords, assuming the chain functions normally, you can download the chain and your vault (that no one else can open, since they don't have your key).
How confident are you that a typical company/project will be around in 20 years? How confident are you that the BTC ledger will be intact in 20 years? Either way, keep a local backup if you can.
On reflection, this is probably not as stupid as it sounds.
The point is using blockchain to store your (encrypted) data. It's not feasible to backup everything this way, but a list of passwords is short enough.
If all you do is open source and the only things you need to back up privately are passwords, this way you can avoid having your own backups at all.
But why would a blockchain be any better than a peer-to-peer filesystem, for example?
Also, it seems like a really bad idea to have your encrypted passwords open for anyone to have a crack at - any flaws in the b.lock encryption protocol or implementation could have disastrous consequences. Unfortunately I wasted some minutes of my life looking into their encryption, and it's bad (not using authenticated encryption, using a malleable encryption mode (CTR), directly encrypting secrets with your wallet private key...)
If you use blockchain for storing secrets, then you signal that you don't know
what blockchain was intended for and what storing secrets needs, in other
words, you signal that you are not competent to build a password store.
No, encryption is for keeping secret a secret, even if it ends up public.
But this misses the point. Blockchain is an implementation of a specialized
cryptographic primitive called "document timestamping". Nothing this primitive
provides is useful for a password manager. About the only thing that would be
useful is much better served with a DHT, and much cheaper, too.
Lots of negativity here that I don’t think is completely justified. I subscribe to a family plan for 1password. I have options to sync with iCloud and several other cloud services, and for the most part that’s great. But I don’t have an option to sync with a service that I can guarantee will remain in existence and outside of state control. I also have to maintain an account in good standing with these services, or potentially host and secure my own hardware.
Blockchains - at least those that are heavily adopted - provide a kind of good solution to this problem. State is maintained by a third party that’s likely to be around for a while, and if I forget or can’t pay a bill for a while, my credentials are still stored and accessible at a later time. I like the idea of paying a little to a third party for the store operation, vs paying a little every month for the privilege of performing a get operation.
On the other hand, you're making a pretty big bet on the correctness of the implementation of the tool. What if, due to a sneaky bug, the tool uses far less entropy than is required to securely encrypt your passwords? If there is nobody working (professionally, for money) to check that the implementation is correct, you're just hoping that your passwords (stored on a public blockchain) were blessed with the correct incantations. As it turns out, getting a proper audit of products like this where there is no central money-having entity is incredibly hard.
> But I don’t have an option to sync with a service that I can guarantee will remain in existence
How does blockchain ensure this? (I'm not sure that blockchain has any particular advantages or disadvantages here compared to the classic "upload it to Usenet" approach to reliable backups.)
> and outside of state control.
How does blockchain ensure this? In particular,
- State still control almost every network connection in the world, and blockchain is meaningless if you can't actually connect to the network.
- Almost all blockchain schemes distribute power in proportion to existing ("real-world") power, e.g., people with the most existing capital, people with the most computational resources, people with the most coercive ability. Wouldn't you specifically not want a blockchain if you're worried about state power executing a 51% attack?
- What, precisely, is a state going to do by "controlling" your encrypted password store? Controlling a cleartext password store, sure, but there are already well-established mechanisms to just encrypt them, no blockchain required. And I don't really understand what a 51% attack on an encrypted file is supposed to do.
Blockchains are very good at one thing: avoiding double-spend attacks in a system otherwise susceptible to Sybil attacks. That turns out to be exactly the problem that a worldwide distributed electronic currency has. But it's not the problem everyone has. If you don't have that problem, blockchains are not particularly useful to you.
Block chain seems like an overkill solution for this though. I could just use open source software like keepass and sync the encrypted password file to a few different local devices and maybe a cloud backup option. If I can't pay the cloud bill, that's fine, I have a few local backups.
Blockchain's most important feature is the shared ledger. But for a password manager, I don't have anything I need to prove to anyone else.
This seems like a use case much better suited to the BitTorrent protocol than blockchain.
In either case, it seems unwise to put your passwords in the hands of absolutely anyone and everyone even if they are encrypted.
It's not a lot of data. There are other places where you could publish a small file for free, provided that you entirely trust the encryption and therefore are willing to make the file public. For example, a gist on Github.
(But personally, I wouldn't publish the encrypted file, just in case.)
Store it with some scheme like TripleSec https://keybase.io/triplesec/ and put it in a private gist on GitHub, so you'd need three encryption algorithms plus GitHub account security to be broken before anyone can get to it.
As they are encrypted you can save them anywhere you want, and even distribute them to a bunch of different services where they won't be inaccessible if one service goes down.
Anywhere. Put them on an HN comment, log in and enable showdead. Stick them in a git repo, revert the commit, and make a pull request to a popular project. Steganographically encode them into the next popular internet meme. Make an account on hashbang.sh and save it to disk.
If you have access to the blockchain, you already have access to a million more reliable data storage options, some reasonable, some not. Blockchain is a distributed consensus tool, not an anti-censorship tool. If you can't reach other random storage services, why do you think you can reach the blockchain?
YCombinator can go out of business and bring HN down, not all internet memes survive long, your disk can be lost in a fire, etc.
I'm not saying blockchain is better, just that it's at least reasonable. Already distributed and can be expected to survive longer than individual companies.
Ever heard of this silly thing called distributed hash tables? And BitTorrent protocol that is currently the most popular implementation, which sets up a whole DHT/P2P network for every share? There, as one example.
How will else will you provide incentives for everyone to store the encrypted secrets?
Without a reward system, this is just a torrent with no one seeding. Therefore, a distributed database without incentives for the world to keep it thousands of times replicated will not do it.
Honestly, I'd like to pile onto the shit-flinging train, but it's gotten so ridiculous that it's wrapped around to not being funny at all.
In fact, anything that is trying to promote widespread electricity usage to run a blockchain for a product that we have good alternatives to should actively be discouraged.
This is actively harmful. It's well beyond the 'considered harmful' memes.
This works the same way as any other cloud based password manager but less secure. Most work like this:
- Store a AES-256 encrypted database blob in the cloud
- Hash your master password using a slow/expensive hashing algorithm, and use the resulting hash for encryption/decryption.
- Offer 2F options to restrict who can requested the encrypted database blob/test the master password.
- Ask for the master password, try to decrypt the header of the blob, if it works return the blob.
This solution stores an AES-256 encrypted database in public, therefore cannot offer 2F, and is only protected by the quality of your private key (and I cannot even see which hashing algorithm they're using).
Someone unironically said in this thread they "never trusted LastPass" (implying this is safer) but technologically you don't specifically need to trust LastPass.
Regardless of if you're using DropBox, Google Drive, or LastPass for Cloud Storage the primitives are the same: AES-256 Encrypted Blob, Cloud Protected Storage (w/2F options), and a hashed master password.
If you want to roll your own LastPass, use KeePass and DropBox with 2F. Not this.
The largest danger is not the key getting hacked IMO, it's the service that you are backing up to going under.
If you had a yahoo email account twenty years ago, and emailed yourself a encrypted password vault, and decided to try to check that email today, how confident are you that it would be there?
Most services, including LastPass let you export your database. In LastPass's case you have the choice of CSV or their own format for "LastPass Pocket" (designed for USB Sticks) or any SQLite compatible tool.
Plus what happens if this Blockchain provider goes under? Unless you have the last version of the chain stored or know someone personally who does, then you're just out of luck. There's no service to even help you find peers to locate a working copy.
I feel like I sign up for websites often enough that I need to access my password vault more often than once every 20 years. When I do that, I can just store it in the most convenient service for me at the time - even sending it to my current email provider would work.
Also, storing my passwords publicly for 20-30 years is probably an antifeature: if you stored encrypted passwords with a state-of-the-art algorithm from 1998, and it were publicly accessible the whole time, how confident are you that it can't be brute-forced right now for $100 of public cloud?
> Someone unironically said in this thread they "never trusted LastPass" (implying this is safer somehow?!) but technologically you don't specifically need to.
There's something to be said about perception. A big corporation making money off a centralized service that uses the money to employ people to get things right? Seems sketchy. Some people on GitHub with a Chrome extension that can read and write all data on every web page you visit and intentionally syncs your passwords with ... AES-CTR with no integrity protection??? please tell me I'm misreading this ... to some random altcoin? Sounds great, these people must have my best interests in mind, hack the planet, fight the power, &c. &c.
The question is, how do we change these perceptions?
Seems to be the case, with non-random nonces... If I read the documentation of the used library correctly, it starts the counter always with 1 by default. Game over?
2. You haven't proved the concept if you're not handling your key material right - among other things, if I'm still reading right, it looks like you're using the (asymmetric) wallet private key as the (symmetric) encryption key for passwords? Is this in any way safe? (Traditionally, the overwhelming consensus of the cryptography community is no.) If you need to generate new keys and unique nonces and verify IVs, you need to figure out how and where you're storing a key before you've successfully proved the concept.
So wouldn't the blockchain become unweildly pretty quickly?
Especially when people start base64 encoding their mp3 collections and storing them in the b.lock chain?
At least with a normal ledger system, you can collapse chunks of history and hash them to validate. But it seems that if you are storing data that needs to be accessible, you can't do that.
I don't have a TB or two to spare on most of my devices.
It's using an altcoin, which is why it's so cheap - because the market has adjusted to correctly price reliable storage in the Bitcoin blockchain (given its importance, number of users, and frequency of updates) and has not yet adjusted to correctly price reliable storage in this altcoin's chain. Or, worse yet, the market has correctly priced it and you get what you pay for.
> Single point of failure: if the server/database goes down, there goes your passwords
I haven't investigated Blockchain too extensively, but: is there not a risk that this blockchain goes down if nobody uses this password manager, much like how you can't download a torrent if nobody's seeding it? Or does it bootstrap itself on Ethereum's blockchain or something?
generally you are correct. But most blockchains have a central "seed" server that is supposed to always be up. Furthermore if the seed server goes down and none of the peers you have previously connected to are reachable you are an island in those cases.
Most blockchains, including as far as I know all Bitcoin based blockchains (including Bitcoin itself) have two types of seeds embedded in them.
First the IP of seed servers (nodes) and second the hostname of a DNS based seed lookup.
The DNS host name as well as the IP addresses of the seed nodes are actually embedded in the source code itself.
They exist for new peers to discover people to connect to. And if the case of seed nodes they also act as peers themselves. If all those nodes and the DNS seed go down.
The DNS is constantly rotated to contain A records for a large number of peers which new peers will randomly pick from.
In the case of Bitcoin the seed servers are all run by different organizations and there are a lot of them. Smaller coins may actually only have 1 or 2 seed servers all run by the same people.
Some blockchains allow multi-cast based discovery but that only helps if you happen to be on the same network as another node.
Right, so compared to a centralised solution it's slightly more resilient, but still largely reliant on an always-up seed server just like e.g. LastPass is dependent on LastPass's server being up?
60 comments
[ 3.3 ms ] story [ 145 ms ] threadA blockchain powered alarm clock would be dumb. Unlike providing incentives for thousands of machines to store a password vault for a long time?
When you need the passwords, assuming the chain functions normally, you can download the chain and your vault (that no one else can open, since they don't have your key).
How confident are you that a typical company/project will be around in 20 years? How confident are you that the BTC ledger will be intact in 20 years? Either way, keep a local backup if you can.
The point is using blockchain to store your (encrypted) data. It's not feasible to backup everything this way, but a list of passwords is short enough.
If all you do is open source and the only things you need to back up privately are passwords, this way you can avoid having your own backups at all.
Also, it seems like a really bad idea to have your encrypted passwords open for anyone to have a crack at - any flaws in the b.lock encryption protocol or implementation could have disastrous consequences. Unfortunately I wasted some minutes of my life looking into their encryption, and it's bad (not using authenticated encryption, using a malleable encryption mode (CTR), directly encrypting secrets with your wallet private key...)
But this misses the point. Blockchain is an implementation of a specialized cryptographic primitive called "document timestamping". Nothing this primitive provides is useful for a password manager. About the only thing that would be useful is much better served with a DHT, and much cheaper, too.
Blockchains - at least those that are heavily adopted - provide a kind of good solution to this problem. State is maintained by a third party that’s likely to be around for a while, and if I forget or can’t pay a bill for a while, my credentials are still stored and accessible at a later time. I like the idea of paying a little to a third party for the store operation, vs paying a little every month for the privilege of performing a get operation.
How does blockchain ensure this? (I'm not sure that blockchain has any particular advantages or disadvantages here compared to the classic "upload it to Usenet" approach to reliable backups.)
> and outside of state control.
How does blockchain ensure this? In particular,
- State still control almost every network connection in the world, and blockchain is meaningless if you can't actually connect to the network.
- Almost all blockchain schemes distribute power in proportion to existing ("real-world") power, e.g., people with the most existing capital, people with the most computational resources, people with the most coercive ability. Wouldn't you specifically not want a blockchain if you're worried about state power executing a 51% attack?
- What, precisely, is a state going to do by "controlling" your encrypted password store? Controlling a cleartext password store, sure, but there are already well-established mechanisms to just encrypt them, no blockchain required. And I don't really understand what a 51% attack on an encrypted file is supposed to do.
Blockchains are very good at one thing: avoiding double-spend attacks in a system otherwise susceptible to Sybil attacks. That turns out to be exactly the problem that a worldwide distributed electronic currency has. But it's not the problem everyone has. If you don't have that problem, blockchains are not particularly useful to you.
Blockchain's most important feature is the shared ledger. But for a password manager, I don't have anything I need to prove to anyone else.
This seems like a use case much better suited to the BitTorrent protocol than blockchain.
In either case, it seems unwise to put your passwords in the hands of absolutely anyone and everyone even if they are encrypted.
(But personally, I wouldn't publish the encrypted file, just in case.)
If you have access to the blockchain, you already have access to a million more reliable data storage options, some reasonable, some not. Blockchain is a distributed consensus tool, not an anti-censorship tool. If you can't reach other random storage services, why do you think you can reach the blockchain?
I'm not saying blockchain is better, just that it's at least reasonable. Already distributed and can be expected to survive longer than individual companies.
…go all down before you can react? Seriously, if you need a secure backup, a couple instances, geographically separated, are more than enough.
Step 1: upload your data on a server somewhere. Your mail server, Dropbox, GitHub, your blog, your virtual server with SSH access…
Step 2: cross the border.
Step 3: download the data.
Without a reward system, this is just a torrent with no one seeding. Therefore, a distributed database without incentives for the world to keep it thousands of times replicated will not do it.
In fact, anything that is trying to promote widespread electricity usage to run a blockchain for a product that we have good alternatives to should actively be discouraged.
This is actively harmful. It's well beyond the 'considered harmful' memes.
- Store a AES-256 encrypted database blob in the cloud
- Hash your master password using a slow/expensive hashing algorithm, and use the resulting hash for encryption/decryption.
- Offer 2F options to restrict who can requested the encrypted database blob/test the master password.
- Ask for the master password, try to decrypt the header of the blob, if it works return the blob.
This solution stores an AES-256 encrypted database in public, therefore cannot offer 2F, and is only protected by the quality of your private key (and I cannot even see which hashing algorithm they're using).
Someone unironically said in this thread they "never trusted LastPass" (implying this is safer) but technologically you don't specifically need to trust LastPass.
Regardless of if you're using DropBox, Google Drive, or LastPass for Cloud Storage the primitives are the same: AES-256 Encrypted Blob, Cloud Protected Storage (w/2F options), and a hashed master password.
If you want to roll your own LastPass, use KeePass and DropBox with 2F. Not this.
If you had a yahoo email account twenty years ago, and emailed yourself a encrypted password vault, and decided to try to check that email today, how confident are you that it would be there?
What about in 10 more years?
Plus what happens if this Blockchain provider goes under? Unless you have the last version of the chain stored or know someone personally who does, then you're just out of luck. There's no service to even help you find peers to locate a working copy.
Also, storing my passwords publicly for 20-30 years is probably an antifeature: if you stored encrypted passwords with a state-of-the-art algorithm from 1998, and it were publicly accessible the whole time, how confident are you that it can't be brute-forced right now for $100 of public cloud?
There's something to be said about perception. A big corporation making money off a centralized service that uses the money to employ people to get things right? Seems sketchy. Some people on GitHub with a Chrome extension that can read and write all data on every web page you visit and intentionally syncs your passwords with ... AES-CTR with no integrity protection??? please tell me I'm misreading this ... to some random altcoin? Sounds great, these people must have my best interests in mind, hack the planet, fight the power, &c. &c.
The question is, how do we change these perceptions?
Seems to be the case, with non-random nonces... If I read the documentation of the used library correctly, it starts the counter always with 1 by default. Game over?
2. You haven't proved the concept if you're not handling your key material right - among other things, if I'm still reading right, it looks like you're using the (asymmetric) wallet private key as the (symmetric) encryption key for passwords? Is this in any way safe? (Traditionally, the overwhelming consensus of the cryptography community is no.) If you need to generate new keys and unique nonces and verify IVs, you need to figure out how and where you're storing a key before you've successfully proved the concept.
So wouldn't the blockchain become unweildly pretty quickly?
Especially when people start base64 encoding their mp3 collections and storing them in the b.lock chain?
At least with a normal ledger system, you can collapse chunks of history and hash them to validate. But it seems that if you are storing data that needs to be accessible, you can't do that.
I don't have a TB or two to spare on most of my devices.
> Single point of failure: if the server/database goes down, there goes your passwords
I haven't investigated Blockchain too extensively, but: is there not a risk that this blockchain goes down if nobody uses this password manager, much like how you can't download a torrent if nobody's seeding it? Or does it bootstrap itself on Ethereum's blockchain or something?
With that said, from the repo. This one is based on https://nebulas.io/
First the IP of seed servers (nodes) and second the hostname of a DNS based seed lookup.
The DNS host name as well as the IP addresses of the seed nodes are actually embedded in the source code itself.
They exist for new peers to discover people to connect to. And if the case of seed nodes they also act as peers themselves. If all those nodes and the DNS seed go down.
The DNS is constantly rotated to contain A records for a large number of peers which new peers will randomly pick from.
In the case of Bitcoin the seed servers are all run by different organizations and there are a lot of them. Smaller coins may actually only have 1 or 2 seed servers all run by the same people.
Some blockchains allow multi-cast based discovery but that only helps if you happen to be on the same network as another node.
Best link I could find with the time I have: https://bitcoin.stackexchange.com/questions/14371/what-is-a-...