Show HN: b.lock – a blockchain-powered password manager
github.com
github.com
- 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.
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.
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?
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.
> 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-...
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.
(But personally, I wouldn't publish the encrypted file, just in case.)
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.
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.
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.
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.
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...)