You have copied LastPass, however LastPass isn't a good design to copy. Passwords and sensitive info isn't only for "Sites". You also have Wifi networks, routers, credit cards, etc, not to mention many people need custom fields, like for Apple's stupid secret questions, or for recovery codes, etc. You've also taken the name Site too literally. Throwing an error if the URL is empty is a mistake. Don't assume the user doesn't know what he's doing and I doubt this app needs URLs to function.
I never liked LastPass because it's rigid on how you can store data. Surely username+password+ website is common enough, but give the user the opportunity to add custom fields. This is how KeePass and 1Password work, it's a proved design ;-)
On Android, when using the password generator on editing a new site, in order to complete the process I had to copy/paste the new password. This is bad, on Android at least, as the clipboard on Android is public and any app can register a listener for clipboard events. And again, on viewing the password, it got truncated, so the user is forced to copy/paste it.
I'm also uneasy about having my data uploaded to your servers. I realize data is encrypted before that, but given this is supposed to be open source, it would have been better if the apps were able to work offline or with Dropbox, then add the server stuff as an add-on.
While it isn't quite as nice as KeePass and 1password, lastpass does have secure notes for things that aren't sites.
I'm not sure when you last checked it out, but the current version of LastPass allows you to create as many custom templates as you like.
Yes, it now allows creating custom templates, but that doesn't work in the mobile apps or in the OS X app, it is clumsy and because it isn't a website, the forms you create won't auto-complete AFAIK.
For android, there is a issue that is being tracked for adding autofill support. iOS already supports this, I just did not have time to get it in for the 1.0.0 release on Android (see https://github.com/bitwarden/mobile/issues/1). Also, I am an iOS user so I do not have a lot of experience with how android "should work" so that makes things a bit slower for me doing development there.
I think KeePass circumvents this by having a virtual keyboard that is used to deliver the passwords securely to the destination application/form. I haven't heard of any better solutions, or any serious attacks against the virtual keyboard method.
Sometimes your only option is copy/paste tho.
I agree 100%. For an open source alternative that offers the same flexibility while still trying to be as easy to use as possible, check out https://padlock.io! (Disclaimer: I'm the author)
Read these two links:
You want AES-GCM or AES-CBC + HMAC-SHA2 (Encrypt then MAC).
"After Lastpass got acquired by LogMeIn last year I decided to start looking elsewhere. Being a software developer myself, I turned toward open source solutions but it immediately became apparent that nothing existed that was as convenient and as user friendly as Lastpass. I also realized that everyone seemed to charge money for these closed-source solutions (and rightfully so I suppose, a password manager is essential!).
bitwarden was born from this search and I have been developing on it every night since. This week marks the complete 1.0.0 release of bitwarden! There are apps for iOS and Android on the stores, browser extensions for Chrome, Firefox, and Opera, and a convenient website vault. It's free, open source, and cross platform.
Feel free to let me know any feedback that you may have or if you are interested in contributing in any way. You can check out the main product website at https://bitwarden.com/"
I truly hope the project will live on and improve even further, but it's already amazingly useful for our team and a pleasure to use.
It's less about 'making a fuss' and more about 'providing additional data to adversaries.' Remember, the NSA piggybacked on Google Analytics tokens for years to track users.
Makes all the sense in the world they'd do so, and I have no recollection of that. Do you have the links to share while I look myself for same? TY
If you want more feedback than just the bugs and feature requests reported, why not ask the users in your software via a friendly dialogue screen after a week or so?
All it would take for all of your customer's privacy and security (mostly their security via obfuscation) to be compromised is for one person to gain access to your google login. If somebody does that, they are instantly gaining access to countless private URLs nobody would know about otherwise in a beautiful easy-to-use interface called Google Analytics.
And then you have "intentions" to do opt-OUT tracking?
You are currently demonstrating your decision making (when it comes to security) is very poor. You really need to think more about your users if you're going to be serious about this project.
I love the work you've done here--we're all looking for a great solution to the password manager problem. But for the love of all that is holy, do not include tracking software in a password manager vault. Do not even include the tiniest thought or idea that it might be phoning home somewhere.
Because with this small, innocent action you ruin all the trust you build in your product.
It's a law not everyone seems to like, but it cannot have had much support from big corps so I doubt it was lobbied in. It's something they apparently care about. I hate all the "will you accept our cookies" screens but overall, I'm actually a proponent of the law. Functional stuff like login cookies are fine (don't need consent) so those screens actually warn us "this website wants to make a behavioral profile or sends your data to third parties who want to do that, you wanna continue?"
EDIT: I actually found a comment from the author on reddit saying they'll license it under GPLv3. https://www.reddit.com/r/programming/comments/56ojub/after_1...
The wording wasn't "we might license it under X", or "I'm considering licensing it under X". The exact wording is:
> I'll have a license added tonight at some point. It will be GNU GPLv3.
Which to me reads as "I'll have a license [file] added tonight...". But meh, that's for courts to decide not random people on the internet cosplaying as lawyers.
EDIT: This is all moot anyway because the author did end up using GPLv3.
I don't want to imply that these things automatically make it insecure, but to me at least they raise questions, and none of your copy appears to address this. Thanks!
PBKDF2 is an standard that is readily available in all the frameworks being used for this product. This is important because all products must be doing crypto the exact same way and this can be a bit of a challenge to keep in sync without a standard. I am also attempting to keep my third-party library exposure to a minimum when it comes to crypto functions. I realize that PBKDF2 is a pretty old function, however, I am not aware of any risks in using it as long as iteration levels are properly increased over time.
AES256-CBC is used because it provides the level of crypto that is needed for this type of application. I realize that CBC lacks the integrity checks that other methods may offer, however, I am not sure integrity is needed to still provide a secure exchange of ciphers from a trusted source as is being done here.
I hope this answers your questions and thanks again for having a look!
1.) Get a master password from the user
2.) Get an email from the user
3.) Call makeKey(masterPassword, email) where makeKey is 5000 rounds of pbkdf2(masterPassword, email) with a resulting 256 byte hash. Seems weird to use the email as a salt rather than random bytes.
4.) Take the result of makeKey and call pbkdf2(masterPassword, hash) for 1 round and resulting in a 256 byte hash.
It just seems odd to use the master password to create a hash, then rerun the same hash algorithm with that hash as the salt.
EDIT: It seems .NET does support it, but only with SHA-1.
 - https://github.com/aspnet/DataProtection/blob/00d593f1f29884...
What would you recommend for resource constrained environments, like mobile phones? PBKDF2 is already very slow (from a UX perspective) on low- and mid-range Android phones. You also don't have the luxury of having tons of RAM available for a memory hard KDF.
I don't trust third-party clouds for many reasons; for one, what's to stop them from holding my data hostage and making me pay a ransom? Or just charging for the service with no (or difficult) alternatives? How do I know the data is backed up well, so a server farm fire won't destroy it? How do I know how secure the cloud is, physically, by host, by software or any other way? I'm sure I could easily come up with a half-dozen other reasons why it's a concern without trying very hard.
I find it hard to believe that any cloud service with some basic primitives couldn't host my data just fine. Why must I use everyone's individual cloud service?
This complaint is no doubt semi-bogus in this case since it's OSS software, and I could fork it and add Dropbox support. That's valid. But everyone is using their own cloud, and it's bothersome.
But Dropbox "or some other cloud that acts like regular files" is a third-party cloud.
Why can't this be shipped with a server that I can host myself without running SQL Server, .Net and whatever else?
The server is just supposed to store already encrypted credentials, right? I'm pretty sure a very small PHP/sqlite backend should be able to do the trick.
Otherwise this seems like great work. Thanks.
I'm currently using KeeWeb on the desktop. Unfortunately the KeePass app available for iPhone isn't that great. KeePass2Android is pretty OK though.
Will take this for a ride.
- Not open source (or in part, e.g. the server side is closed);
- Uploads stuff to the cloud (I want to self-host);
- Not available on mobile;
Bitwarden sounded quite good at first: mobile, sync and open source. I can inspect the code and run the web part (the vault, they call it) myself. Then I had a look at the web part:
It's C#. I'm not going to run a Windows Server just for this.
Additionally the DB Backend is MSSQL which "is" linux compatible (kind of), but if the author addresses this as well:
Then it should be runnable pretty easily on linux. So it isn't cross-platform yet but it seems that's part of the plan.
Seems like you are making a fuss about a piece of software that you didn't really bother learning how it actually works.
I want to use a password manager, I just can't find any that work everywhere and don't depend on third party services (and I want to inspect the source code). I'm not making a fuss on purpose.
- Open Source
- Cross Platform
- It appears to be possible to host your own server
- As pointed out somewhere else, Bitwarden is very limited in what you can store. It seems to be primarily for storing website logins and does not offer any customisation options for storing other kinds of data. Padlock is much more flexible in that it allows you to add any number of fields to any given record.
- Apart from the mobile apps, the primary way to access your data seems to be the website served over https. This is a terrible idea for a ton of reasons and I could spent all day going into all of them but lets just say that there is simply no way to handle your data in a secure and private manner this way (either you have to do crypto client-side which is inherently insecure for a website served over the net or you have to do it server-side which means you have to send your master password to the server). By contrast the Padlock app, although based on web technologies (it's built with Polymer), is only available as a packaged (and code signed!) app for all platforms. This means that you can safely do client-side encryption without having to worry about the integrity of the source code. Padlock Cloud on the other hand is built on the principle of Zero-Knowledge, meaning no unencrypted sensitive data is ever sent to the server.
I could go on forever, but this will have to do for now. If you have any specific questions, let me know!
For example, I can create a password in KeePass on my phone, for a new app. I can then immediately open KeePass on my PC, find the new credential, and sign into the app's website. Dropbox handles all the file updates in the background.
> The product is currently sponsored by the Microsoft BizSpark program (see https://bizspark.microsoft.com/) which provides services in Azure. The product website and web vault are hosted as static GitHub pages. Everything else is a client-side application.
"Hi all. I am the author of this project if you would like to ask any questions. Many have been answered on Reddit already but I will participate here as well."
Only users who specifically enable "show dead" in their profile can see your. They are read only and can not be replied to. It is quite likely most users can not see them, as show dead is opt-in only.
If you as a user; or this post have been flagged as spam/other (likely) you should reach out to HN via their contact info which I believe is listed in the guidelines section.
You shouldn't litigate this in the thread (nor would anyone see it) but, Dang is often quick to respond and both quite helpful and reasonable to legitimate inquiries.
Bitwarden looks to be quite interesting. The client on ios does not support the 5c, which is a shame since I have one. Curious if there is a hardware limitation as the service appears cloud-based and it would be nice if a software solution existed for users of slightly older phones.
Only a guess: the iPhone 5C shipped with the A6 processor, while Secure Enclave was introduced with the A7.
/edit nope, original author responded with the real answer :)
Unfortunately I can only support the ARM64 architecture for iOS currently due how Xamarin builds the project. When I introduce additional architectures (i.e. ARMv7) it increases the size of the app from 50mb to 100mb.