Show HN: Password.ly - Per site password generator from a master password | Hacker News Reader

Show HN: Password.ly - Per site password generator from a master password

password.ly

16 pointsqixxiq54 comments

It is not safe to enter your master password on a random website like password.ly. The risk is simply too high that it gets hacked someday and your master password will fall.

That it is not stored in a database is only a small advantage. If whoever controls password.ly wants to have all passwords, she could do so whenever she wants, a matter of a simple extra request. It could even be hidden in the params of any link on password.ly (to prevent you from noticing the extra request).

And that reveals the second big problem with this: The master password is basically every password. If it falls in the wrong hands you are worse off than you would be if you have a small set of passwords, which isn't a highly recommended strategy in itself.

But the idea itself isn't too bad, if you would instead of using password.ly use a terminal bcrypt command to bcrypt your password+sitename it would be very decent indeed.

The only way sites like this could be safe to use is if there would be a code-signing standard for the web.

edit: This service actually sends your password to their service! At first I thought it was an innocuous enough javascript password generator, but this is so stupid it borders on malice..

There is a command line client too, and the entire website is open source (links at bottom.)

If you're worried about not trusting anyone, then you would need to set up your own solution - but for most people thats completely out of their league. This is intended for people who would be typing their master password in different websites, and now instead only need to type their master password into one.

I can't argue against the problem of only having one password, but the small set never worked for me. I have a couple plans to integrate password migration into password.ly.

> and the entire website is open source (links at bottom.)

How do I know the code released for review is actually the code they're running on their server? There is no way they can adequately prove this to me.

Simple solution is to self-host it.

I understand your point, I've thought about launching a site like this too, but the single host problem is just too big of a flaw.

It has nothing to do with trusting anyone, if a service like this should grow out of obscurity it would naturally become a target for hackers, just like the Bitcoin exchanges did for example.

There is almost no protecting against this, the attack vectors are endless, and the bounty could be very large.

Since all this can be done client side, you don't really want/need to give your master password away. We built an app like this - its a chrome app and everything happens in your browser.

https://chrome.google.com/webstore/detail/password-generator...

Source: https://github.com/agiliq/forgot-me-password

Its not as good as this as we use use MD5 to hash the generated passwords - reason being this was proof of concept, and built mostly for our use. If anyone wants to add bcrypt - pull request is gladly accepted.

I ported scrypt to the browser for this sort of thing, you can find it here:

https://github.com/d-snp/scrypt.js

Note that some other guy wrote the javascript which was made for Node, I merely changed some types so it would work in the browser, I actually have no idea if it is still secure :P

Note btw, that as soon as tptacek wakes up he'll wack everyone around with his staff until we understand that we are fools for messing about with javascript security.

And he should, because he would be right for it. This whole article should be banned, and I have flagged it, because it is a terrible idea and no one should be fooled into using this service.

MD5 is a no go, SHA-256 would at least be better. I will look at your sorce though. Bcrypt might be too heavy in plain JS if chrome doesn't offer it as a part of its api.

But I agree, this should be a browser extension, not a website.

Edit: btw, found this: http://www.lorrin.org/blog/2011/06/15/a-fruitless-search-for...

Just use: http://code.google.com/p/javascript-bcrypt/

Absolutely agree. Using something saner, has been on my todo for a long time.

Looks like there are a few bcrypt js library - why would using them be too heavy?

I strongly recommend against using the Chrome app linked in the parent post. It uses a simple MD5 hash to derive the site-specific password from the master password, making it much easier for a site to use a brute-force approach to get the master password from the site-specific password. In addition, it seems that the code retrieves effective_tld_names.dat from Mozilla's server every time a password is hashed. Apart from performance considerations, this file is retrieved over plain HTTP giving adversaries another potential attack vector (by tampering with the version of effective_tld_names.dat sent to the browser).

The passwords generated by this do not have enough entropy. The code that does the generation is:

  def generatePassword(password, site):
    letters = 'abcdefghijklmnopqrstuvwxyz'
    u_letters = letters.upper()
    all_letters = letters + u_letters

    numbers = '0123456789'
    symbols = '!@#$%*-?+='
    length = 10

i.e. a 10 character password is generated from an alphabet with 72 characters in it. That gives 10 * log_2 72 which is roughly 61.7 bits.

Currently you'd want to have at least 80 bits for a good password.

Of course, it's trivial for them to fix this given that they are generating the passwords: just change length to 13 or greater.

I'm curious to know where the 80 bit number comes from? The 61 bits seems like a crazy large number to try and brute-force, but perhaps there are other issues besides brute force that I'm not considering?

Unfortunately while changing the 10 to 13 was a rather trivial change yesterday, now that the site has launched its not really possible. It would change and break everyones password on the site.

That said the entire thing is open-source, so anyone 'could' set up a version of password.ly with length=13 for themselves if they wanted.

Probably from NIST Special Publication 800-63. Level 3 authentication requires cryptographic keys with an entropy of at least 80 bits. http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1...

You should consider making the password generator versioned, there may be many breaking changes between now and the day it dies.

I think 80 is overkill. I'd say anything above 60 is secure enough for most passwords. One of my main password (consisting of only lowercase letters) has an entropy of 78.7 bits, which is good enough to safely guard sensitive information like financial records, but then again, it's 21 characters long :)

It has less entropy now that you've given away some information about it.

A 21-character password chosen randomly from [a-z] would have about 98 bits of entropy. But better be random.

Matters not. You still have no idea which one of my main passwords, how many they are nor where its used. Also, this particular password is non-critical which is why I used it as an example, but you're welcome to try and hack my accounts ;)

Have a look at your competition such as; http://supergenpass.com/

Your system is creating the passwords server side and so taking the user's "master" password in. Where as SuperGenPass is purely javascript based and runs completely in the browser; thus is safer.

Also being a bookmarklet make's it more convient, as you can just click the button from within your browser toolbar, rather than having to go to a sepearte site, remember exactly what you put in the "Create password for:" input, did you put the domain with a www or without? with http:// or https:// ?

That's something I didn't like about it either -- my tin-foil hat clamped on a little tighter when I realised that your entry is fed into the server, mangled, then your new password pops out. That seems like a possible insecurity.

It appears like you're using the flawed '2a' bcrypt implementation from 2011, ex:

    <input type="hidden" name="hash" value="$2a$11$1aRIk1567CsvOEGMEKlalOteGiqsy9APgBfI/5ZtPJvQgQkvxC1.G">

Use the '$2y$' form to ensure you're using the fixed version, at least, though I recommend something more along the lines of scrypt to be more robust against attack. And do you really need to pass the value in plaintext in the returned form? Just pass the hash value of the master password and put some fake stars in the form field to reduce the possibility of an attacker gaining the plaintext version of the master password from the browser.

All of this of course ignoring the problem of just generating lists of passwords based on commonly-used master passwords and service names, but i'm sure you all realize that problem.

If I want to change a non-master password (some random forum I use gets hacked, for example, or an admin forces a password change), how would I do that?

have to change the name of the website, there are only 2 inputs

So now I need to seperately track which name I actually used for each website on password.ly ... This doesn't scale.

http://keepass.info/

I think a web-based solution that is accessible from anywhere (incl. mobile) is pretty useful.

KeePass works on almost all mobile platforms, even those without web access, and KeePass isn't going to have downtime like password.ly.

The biggest difference between password.ly and most other tools (including keepass), is that each password on password.ly is generated from your master password.

There is no database to lose, or not have access to if you're on another machine. It also has a command line client which works completely offline (though has sync if you're signed up and want to save sites/comments)

That is also a significant weakness, as revoking or changing passwords becomes very difficult.

Except that you should be changing the master password and other important passwords (e-mail, bank, Paypal, Mint) with some frequency. This scheme basically never allows for that to happen.

There's no official Android/iOS app. It feels like an unnecessary risk to use apps from different developers which can't easily be verified against their source.

There's no official app for anything except Windows. They're all open-source, though.

I think this is a good idea for a site, but I'd caution that it could give users a false sense of security. As the site gains popularity, the site-specific passwords are only as secure as the master password used to generate them. Therefore it is still important to choose a strong master password when using this tool.

This may be obvious to users here, but to most people the fact that the generated passwords seem random may lead to a false sense of security in this matter.

The site seems to suggest it will only generate passwords in the moment. But the text of the site mentions you guys saving them, and your comment mentions a command line tool. How can I find out the extent of password.ly?

My initial impression was "no thanks" because 1Password will type my passwords in for me, a huge benefit. But maybe password.ly can or soon will do this?

In other words, IMO the landing page doesn't have enough info.

EDIT: ahh, now I see the link to the command one tool at the bottom.

Hey,

It's really just a MVP at the moment. There are quite a few improvements planned, and definitely a browser extension if there is any interest.

At the moment it is limited to the password generator, site names along with comments saved when you've signed up and a simple command line tool.

Cool, just trying to give honest feedback. Which can be hard to do with out sounding like a jerk :) I'm glad to see more people in this space, solving the password problem is something that interests me.

What do you guys think about the security of 1password? I've been using it for a while and now have a unique password for every site, as long as the site will allow. The chrome extension is pretty good except sometimes I have to click it a few times before it opens.

Though I recently had to wipe my android phone and getting those long passwords in to every app was NOT fun.

This merely gives the user a false sense of security. What if a hacker get hold of your master password? I rather advocate the use of different high-entropy passwords divided in security tiers. A junk password for places you don't care about or fully trust, a generic password to use on trusted services and secure passwords for crucial services.

The master password is an Achilles heal in all of these systems. Granted, it is even more of a weak point in password.ly.

Which is why I am against such services. Imho, they do more harm then good.

People would have to gain access to my machine, plus figure out my master password to compromise me. But I gain unique, random, 24-32 character long passwords for all my log ins. I think the benefit greatly outweighs the risk.

I don't know a lick of Python, so I can't check properly, but does the CLI client[1] work entirely offline, or does it also send the password to the server for processing?

I think I already know the answer (it does), but maybe someone can correct me if I'm wrong.

[1] https://github.com/passwordly/pw

No, it doesn't.

There is a 'pw sync' command which does send your password to the server (in order to confirm your access while updating saved comments/etc) but that is all.

Thanks for the answer.

I'm a bit low-tech in regards to my password scheme, but here's how I do it:

First, I generated an 8 character password using pwgen (great program, btw) that is just mixed-case. I then add several characters based on the name of the website/service I'm logging into.

Using this, I can easily remember my password to everything, and each one is unique.

Even that is not particularly secure since if someone discovers your password is "j8t3$£$hackn", they could easily guess your amazon password is "j8t3$£$amzn" and your reddit pass is "j8t3$£$rddt". Or brute force just those last few chars and benefit from a much reduced search space.

If you are adding to the 8 char password you aren't creating unique passwords. They share the initial 8 chars with each other. Still, this method is much more secure then using password.ly.

Not sure, why this hasn't been mentioned: https://chrome.google.com/webstore/detail/passwordmaker-pro/... It is a port of Password maker pro for firefox. It has been working great for me.

Vault – https://getvau.lt/ – is basically the same idea, taken much further: it lets you control the character classes used in the generated password, and the command-line version can save per-site settings if you choose.

I second this. I have used this solution since I first saw it and it works perfect. The source is open so I can host my own version and it is all done in javascript. I think this is the most secure way do to this.

I feel like this is no different than passwordchart.com but is a bit less configurable. I use 1password myself after using passwordchart for a while. Ever thought about how to handle services that require you to change your password every few months?

I would love to see something like this or a browser tool integrated with a Yubikey. Yubikey has a static password generator. Could it be combined in a browser plugin or does it need a client executable to be secure?

Good one if you'd never change your password. Say I generated a password for my HSBC account with this. Later, if they ask me to change the password, I'm out of options because it's one password per account.

Reply on news.ycombinator.com