[jackjeff]

It needs to be improved to be secure

- salt. To avoid rainbow table attacks. One could use the login/email as salt

- key strengthening function. Instead of repeating naively SHA-256 a few times, use PBDKF2 or even better, something which is also memory hard like scrypt.

Finally. What happens when the password requires to have upper case, symbols, x number of digits, min or max number of characters... If you think about it, some websites have conflicting requirements.

[stepstep]

A salt is random bits added to a password. Hashpass prefers to be stateless, so it just asks the user to pick a strong password (possibly by adding random bits like a salt). It puts more trust in the user, which obviously comes at a price.

Re key strengthening: Agreed, but only salt-less schemes will work in this stateless model. Unfortunately they are few.

> Finally. What happens when the password requires to have upper case, symbols, x number of digits, min or max number of characters... If you think about it, some websites have conflicting requirements.

Addressed this in the article: "Some websites have certain requirements on passwords, e.g., at least one number and one capital letter. A simple way to meet such requirements is to append something like A9! to the generated password (and remember you did that)."

[desdiv]

>Finally. What happens when the password requires to have upper case, symbols, x number of digits, min or max number of characters... If you think about it, some websites have conflicting requirements.

It would be great if there was a site ran by a widely-trusted body (EFF for example) that tracks the various password requirements and limitations of websites. That way password managers, such as this one, can query that authoritative database for the idiosyncratic password rules for each domain and generate a password of the maximum allowable length and with the largest possible alphabet.

[cm2187]

Buy what if they change their requirements? Then you need state (when the password was created).