
Yith Library: an open source web password manager - vibragiel
http://yithlibrary.com
======
kijin
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.

~~~
lorenzogil
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...](https://trello.com/board/yith-
library/500ed56c6a349ea103536216)

Anyway, thanks a lot for your valuable feedback.

~~~
belorn
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.

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

------
raphinou
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.

~~~
TomasSedovic
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.

~~~
darklajid
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?

~~~
TomasSedovic
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/>

------
mazsa
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...](http://www.clipperz.com/support/user_guide/onetime_passphrases)

------
qwerty69
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.

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

~~~
belorn
> 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.

------
EwanToo
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.

------
martinced
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.

~~~
toyg
_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.

