Yith Library: an open source web password manager | Hacker News Reader

Yith Library: an open source web password manager

yithlibrary.com

39 pointsvibragiel18 comments

The landing page, albeit nicely designed, could be slapped onto virtually any online password manager with minimal modifications. While it does a relatively good job explaining what the product does and why it's important, it doesn't do a particularly good job explaining how Yith is different from all the other password managers that are out there. After all, password management with client-side decryption and cross-device sync isn't exactly news these days.

So, what's special about Yith? What problems does it solve that other password managers such as KeePass, LastPass, etc. don't solve? Here's what I can tell from the landing page:

1. Yith is open-source, whereas some of the alternatives are closed-source.

2. Yith doesn't keep the master password in memory any longer than the time it takes to decrypt a single stored password. Most of the alternatives such as LastPass remember the master password (or the private key that it decrypts) for the duration of your browsing session (or for as long as the standalone app is running) unless you explicitly log out. So Yith might be more secure, but it also has the potential to be rather inconvenient.

What else? Is this a web app that you open in another tab while trying to log into a site? Or does Yith come with plug-ins for popular browsers? The "clients" page only lists a web app.

I'm one of the authors of Yith Library and you are right about our landing page not really explaining what makes Yith Library different.

You can read a little bit more about it at my blog http://www.lorenzogil.com/blog/2013/01/13/yith-library/ to understand the reasons about why the product was born.

Having said that, obviously the most different point about Yith Library is its license (GPLv3c) which mean, among other things, you can install it on your server.

We don't have any browser plugins yet so the auto login feature is far from being done.

In the near future I plan to add two important things:

- Another client. Probably a command line utility.

- A sharing passwords feature where you can share a password with a friend or coworker. This would use a combination of asymmetric and symmetric crypto in order to avoid the server to see the master password.

There are many more items in our wishlist, which you can see at https://trello.com/board/yith-library/500ed56c6a349ea1035362...

Anyway, thanks a lot for your valuable feedback.

About the landing page, the link to the github is quite hard to find. Initially I didn't find it, and it was only after reading your comment about installing it on ones own server that I made a second more closer search and found it.

Adding a download link in the footer would make finding that link much much easier.

We added a Github ribbon on the top right corner so hopefully now it is much easier to find the source code.

I once started developing such a tool, but abandoned it when I understood the web browser is not a safe environment.

You can't trust the javascript you execute: http://www.matasano.com/articles/javascript-cryptography/

For another example, imagine a security breach on the server, some malicious javascript code injected server side, and your passwords get leaked, without you noticing.

If you think that you don't have to use SSL because you encrypt client side, think again. Without SSL a simple proxy can inject javascript in the page and get all your passwords.

The best solution I think, which I haven't had the time to implement yet, is a native app, retrieving only encrypted and signed data from the server.

They seem to be using TLS, but yeah the users have to trust Google (which hosts their jQuery js), Mozilla (which hosts their Persona js) and of course the admins of yithlibrary.herokuapp.com itself.

If any of these gets compromised, the crackers would be able to retrieve the master password of any user entering it afterwards.

Wouldn't it be possible to host it on your own server, including the 3rd party files?

And wouldn't TLS in this case protect the full session?

You still have to trust the source, but - it's on your machine. Go read it if you want?

It would and they should do it. But the whole thing would still be fundamentally insecure. Read the link submitted by raphinou:

http://www.matasano.com/articles/javascript-cryptography/

Indispensables: zero knowledge http://www.clipperz.com/security_privacy , offline copy http://www.clipperz.com/support/user_guide/offline_copy , one time passphrases http://www.clipperz.com/support/user_guide/onetime_passphras...

Cliperz (https://github.com/clipperz/password-manager) is another alternative for an open source online password manager. A key feature is that it encrypts all information locally via javascript so the master key is never send over the wire.

For people who went to check: it's AGPLv3. So yeah, you can modify it, provided you do some other stuff as well.

> provided you do some other stuff as well

A common misconception. AGPLv3 only require that you do not remove existing interface to access source code.

As long you don't go out your way in removing access to the source code, you can use a AGPLv3 web service, modify it, and use yourself without needing to read, understand or follow a single line of the license. No additional "stuff" needed.

Fantastic to see a project like this underway, I'm a happy lastpass user but an open source version is a great long term project.

As long as people shall keep thinking that the very concept of a master password you enter on your computer ain't totally broken from a security point of view I won't be surprised by all the security exploits out there.

It's the very mindset of people working in this field which is totally broken.

If someone installs a keylogger on your computer (eg thanks to, say, a 0-day Java applet vulnerability) and gets your master password, it's much much worse than if the same keylogger gets installed and manages to steal only some of your passwords.

For example I connect about once a year to MoneyBookers (where I have money). I connect rarely to the "admin" account of our Google Apps for Business/Domain (because things are correctly set up and just working nicely for our use cases). etc.

I a keylogger is installed on my system, there's a chance an anti-virus or even the user is going to notify, at one point, that something spooky is going on. And between the time the keylogger (say by re-installing the OS) got installed and its removal, I may very well never have connected to MoneyBookers, Google Apps for Bussiness's admin account and all the other sites which I very rarely connect to.

So although the security breach is terrible it is not anywhere near as bad as if my master password was sniffed by a keylogger and the attacker had access to all my passwords.

Note that a 0-day exploit and a keylogger aren't science-fiction: these are the kind of exploits happening on a daily basis and affecting a lot of people.

How can anyone possibly that a master password can ever be secure?

It cannot. It is the anti-thesis of security.

It is trading security for conveniency.

That trend in our industry and the fact that devs don't see what's deeply wrong with that scheme is frightening.

I have nightmares about what's coming in the future because, obviously, we're living in a world where nobody cares about security anymore.

Btw I'm the kind of person who boots a live Linux CD to connect to my online bank account and who did set 2 form factor auth wherever possible. So I'm unlikely to take fanboism and blind faith to the "master password" cult seriously.

Explain me how a master password isn't trading security for conveniency and I might listen.

Well your whole point can be addressed easily. Here is how:

There is no immediate access to all passwords at once. Even when editing/deleting stored accounts, you can only do so by either providing the current one, or by load control.

Normal use, wouldn't need more than a few passwords at any given moment and if there is a request for more, this can be an alert/lock that requires an SMS or any other 2nd means of authentication.

The only real concern is that attack vectors to a single account (eg a gmail account) are broader that way - you can also go through the master password thingy. So, to begin with, if there is an account that is super sensitive you don't delegate it to a master account for authorization, and everything is dandy.

The point of password managers and master passwords is not ultimate security (such goal would be futile). Instead the point is to bring major security improvement to the masses. Eg to the masses who are currently using a single weak password across many websites.

Sometimes you need to trade some security for convenience, or you will lose all security.

edit: In addition, to combat keyloggers (and other malware) you need either HSM or one-time passwords. In both cases you usually need support at the server-side. As such, combating keyloggers is really infeasible via password policies.

Explain me how a master password isn't trading security for conveniency

Entering any password is trading security for conveniency. After all, the most secure server is the one that won't allow anybody to log on, or even better, a shut-down machine without a network cable!

Security is always a trade-off, and if you can't understand that, then maybe your mindset is as broken as anyone's.

so why not use a master password with 2 factor auth ? then the password is useless to a keylogger.

Reply on news.ycombinator.com