Show HN: b.lock – a blockchain-powered password manager(github.com)
github.com
Show HN: b.lock – a blockchain-powered password manager
https://github.com/blockproject/b-lock
60 comments
We have improved our encryption algorithm, please review it at our more recent post: https://news.ycombinator.com/item?id=17394807
Please stop.
What about a blockchain-powered alarm clock? 51% could decide NOT to wake me up in the morning.
That is a good one. The whole world can decide that tomorrow is a holiday.. just because
But... why? If this isn’t peak “because we fucking can, that’s why,” then what is?
Came here to say this. Why? What defect of password managers can you possibly be fixing by adding a global trustless append-only ledger to it?
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?
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.
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...)
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...)
this has strong potential. i never felt safe with services like lastpass.
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.
What is wrong with making an encrypted secret - public? Isn't this what encryption is all about?
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.
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.
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.
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.
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.)
(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.
Everything's just better when you sprinkle a little bullchain, urgh, blockchain on it.
You can do exactly the same thing without blockchain.
And store the encrypted passwords where?
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?
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.
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.
What are the odds that Dropbox and HN and a dozen popular internet memes of your choice and your local computer and your phone and your blog and…
…go all down before you can react? Seriously, if you need a secure backup, a couple instances, geographically separated, are more than enough.
…go all down before you can react? Seriously, if you need a secure backup, a couple instances, geographically separated, are more than enough.
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.
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.
My machines?
Now you have to think about backup, transporting across borders, etc.
Here's how you transport over borders. Works with plain text as well as encrypted data.
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.
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.
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.
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.
- 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?
What about in 10 more years?
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?
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.
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?
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?
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?
> AES-CTR with no integrity protection???
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?
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?
Yes we need to change the encryption algorithm. This is just an proof-of-concept that is still being worked on.
1. Please say that before people use it. Nothing at https://github.com/BlockProject/b-lock or https://blockproject.io/ says "proof of concept" or "you shouldn't use this yet."
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.
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.
We have improved our encryption algorithm, please review it at our more recent post: https://news.ycombinator.com/item?id=17394807
reply
My current password file is almost 1 MB.
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.
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.
One of the advantages mentioned is:
> 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?
> 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.
With that said, from the repo. This one is based on https://nebulas.io/
With that said, from the repo. This one is based on https://nebulas.io/
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?
This is the first time I've ever heard of "seed servers". Do you have any links explaining such a precedent?
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.
Best link I could find with the time I have: https://bitcoin.stackexchange.com/questions/14371/what-is-a-...
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-...