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.
> 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 ;-)
While it isn't quite as nice as KeePass and 1password, lastpass does have secure notes for things that aren't sites.
Thanks for the feedback! I agree that the whole site model may have been taken too far. I have plans for adding other "types" that will support other models. As a first simple step, we can add a free-form notes entry that you can put in whatever you want along with a descriptive name.
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.
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.
> 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 so can listen to it. And again, on viewing the password, it got truncated, so the user is forced to copy/paste it.
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.
> You have copied LastPass, however LastPass isn't a good design to copy.
> 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
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)
You're using AES-256-CBC without authenticating the ciphertext. Your threat model might preclude chosen-ciphertext attacks, but every crypto code auditor will flag that as suspicious (if not an outright vulnerability).
"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 don't know how much development went into it since it was abandoned by Mitro / adopted by Passopolis, but Passopolis is live and I'm using it very happily.
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 would be really wonderful if the password manager didn't contain surveillance software, monitoring every time the plugin has been opened via Google Analytics. Can you remove that?
I had a feeling people might make a fuss about this. I am really just using it to learn about how the product is being used at the moment since it is so new and I would like to improve the experience for people. I have intentions on adding an opt-out flag in settings for this.
If you do that, it should be one of the first questions asked when the plugin first starts up and be absolutely transparent about what data is collected.
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.
Tempting and understandable from the developer's perspective, but it is absolutely unacceptable in a password manager. The notion of usage telemetry gathering does not align with the high level of privacy and security a password manager should represent.
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?
You made software to make peoples secrets more secure but you added tracking, making everything less secure? What were you thinking?
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.
Note that this tracking without prior consent is illegal in the EU.
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?"
Can you please specify the license of all of the projects? As far as I could tell within 5 minutes of checking, none of the projects have license information. A project without a license is actually proprietary (not a free software project). Thanks.
While that is true (and I agree in principle), I'm actually fairly sure that a promise "the current license is GPLv3" is as legally binding as actually putting the license file in the repo -- since it's a statement by the copyright holder of the licensing.
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[1].
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. You can view the project source at https://github.com/bitwarden or the main product website at https://bitwarden.com/
I'm unfamiliar with the C# ecosystem and am curious about whether this is cross platform or not. With the MS freeing the .NET bits it seems like it should work except that it mentions that it uses SQL Server, which I didn't think had been freed. Thanks.
This is an ASP.NET Core application, however, it references the full .NET Framework currently (instead of .NET Core which is full cross platform). I am working to make it run on .NET Core but it requires some third party library dependencies to be addressed first. This is being tracked here https://github.com/bitwarden/core/issues/3 . I anticipate this to run on .NET Core in the near future and therefore be truly cross platform for Windows, Mac, and Linux.
Why did you choose C# and AST.NET Core, instead of another cross platform solution? Was it just your familiarity with the language and platform, or are there other strengths to these over alternatives?
This primarily just comes from my love for the language/framework and long professional history and expertise of using it for building web applications.
Your crypto choices seem somewhat unusual. PBKDF2, while not necessarily unsafe, is a fairly old KDF to choose for a new product. Can you go into more detail about your rationale for choosing this over newer KDFs? Why did you choose AES256-CBC over other, safer modes? Why are you doing crypto in javascript despite shipping browser extensions and mobile clients?
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!
Thanks for the question. Sorry I couldn't get to these questions sooner as I have been overwhelmed a bit with all the questions and feedback rolling in.
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.
Crypto is only done in Javascript for the the website and browser extensions. Maybe I am not understanding your question here fully, but I am not sure of any other way to handle Crypto on the client side for these environments. For the mobile products, crypto is being done using local CommonCrypto (iOS), BouncyCastle (Android), and .NET.
I hope this answers your questions and thanks again for having a look!
The logic through the system is for actually hashing a password is a little strained, and I'm not sure if it's obviously secure or not:
psuedo steps:
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.
So a 256 byte key is created from the 'master password' and email (as salt) with 5000 rounds of pbkdf2. Then the result is used as a salt for a single round of pbkdf2 of the 'master password' again.
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.
Thanks; this is really helpful to know. I'm in the process of converting a bunch of repos to .NET Standard so it looks like I can just ditch the PBKDF2 NuGet package.
> Your crypto choices seem somewhat unusual. PBKDF2, while not necessarily unsafe, is a fairly old KDF to choose for a new product. Can you go into more detail about your rationale for choosing this over newer KDFs?
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.
The slowness generally is configurable parameter ("work factor" or some such) and the value is a trade-off between security and usability. The choice of KDF does not really enter into the picture, I think all of mainstream ones can be configured to be fast enough for mobile devices.
Is there any real advantage to using, say, scrypt or Argon2 if you're going to be turning its work factor down to "PBKDF2 level" anyway? I could be wrong, but seems like diminishing returns. From a practical point of view, PBKDF2 ain't broke and is already available out of the box almost everywhere.
Is it just me, or do custom clouds make people nervous? Why can't it be on Dropbox or some other cloud that acts like regular files?
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.
Also, how long can this possibly be centrally hosted before questions of business model come into play? This seems like something that will go dark in a year tops.
This is a PM asking, so please bear with me. I understand the argument that when the source code is available for inspection things tend to be more transparent, because it would allow the community to identify and remove backdoors or likes. But when it comes to distribution, e.g. via Play Store, how can the end users know the version made available for installation is "A" (with backdoor) or "B" (without backdoor)?
Ideally you would be able to build it yourself and compare the checksums, but often that requires some extra effort to prevent particulars of the compile environment from affecting the binary. Debian is working with moderate success to make their packages reproducible.[1] On the Android side, F-Droid builds apps themselves from public repos.[2]
To the author: the title here and the homepage claims this is Open Source, but I'm seeing no license information in the repository. Please clarify the license.
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.
There are a few reasons why I don't use stuff like 1Password or LastPass:
- 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 written against .NET Core which is cross-platform, however a handfull of the project's libraries haven't been ported to Core from the Full framework yet. See:
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.
Thanks! Well, since I've got your attention, how does Padlock Compare to Bitwarden? Maybe you could point out some major differences in what works better in Padlock than in Bitwarden? What doest Bitwarden do better and how does Padlock plan to improve? (Although, this may not be the right forum for this...).
Yeah, maybe not the right forum to cover all of your questions in detail but here are a few bullet points (note: I cust came across bitwarden, too, so this is just from what I gathered from the website and the little time I've spent playing around with it):
Similarities:
- Open Source
- Cross Platform
- It appears to be possible to host your own server
Differences:
- 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!
When it comes to a password manager I want to pay for it. I personally use 1password and trust them. I want to pay for a reputable service that is specialized in it and is interested in providing security and maintenance.
Nice project, I like my flat-file password manager though, KeePass. Also OSS, and agnostic to how to store/share the database (both an advantage and disadvantage).
KeePass works very nicely on top of Dropbox and other cloud storage. The KeePass Android app interoperates with the Dropbox Android app, handling password and key file sync and updates.
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.
One feature I like in 1Password is Wifi-sync. Passwords are synced between a phone and computer instead of using the "cloud". Is this something you would be interested in implementing?
There were two questions on Reddit that hasn't been answered I think, one was how is the cloud server being paid for and how is data being stored and transmitted?
> 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.
The author (xxkylexx) the posted on this page but has been marked as dead. Maybe a false flagging?
"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.
Thanks. I reached out to the email listed in the guidelines.
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.
Thanks, that clears it up. I have never used xcode but if there is a straight forward way for me (and other users) to load it up, that would be cool. If there is no way to add a legacy client to the app store, it might be good for adoption to have a link to docs explaining the process (if it is easy enough) to put it on older phones.
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.