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.
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.
Adding a download link in the footer would make finding that link much much easier.
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.
If any of these gets compromised, the crackers would be able to retrieve the master password of any user entering it afterwards.
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?
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.
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.
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.
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.
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.
