Show HN: Keep your customers informed and aware

• I generate very long passwords (50 characters by default) with 1Password. I usually include special characters—the one I used included ',{<' and the asterisk.

• The signup field accepted my password—and the signup email included the password I had provided in cleartext…at least it did up until the '<' (where there were probably another ~20 characters left).

• Neither the password as I used it nor the truncated version that I was sent works to log me in.

Implementing PBKDF2 isn't that hard, even in PHP (http://mark-story.com/posts/view/using-bcrypt-for-passwords-... it took me two days to implement, test, and deploy a migration on Rails (and that's only because I'm a cautious SOB who doesn't want to make a mistake affecting customers and we had two tables to do it against with two different password types). If you're offering this to businesses, you should do everything you can to protect their data—even if you are in beta. POF can get away with storing plaintext passwords, or sending them to customers, but you shouldn't do that.

For example:

Retailer: "You'll be pleased to know your product has been dispatch and is on it's way for delivery tomorrow morning"

Estate Agent: "We have a viewing book for your property at 11:30 on Friday"

Digital Agency: "We have published wireframes of your project for you to review"

You are not closing the div (class .btn.btn-danger) so you have an open element when you try and close the list tags.

I noticed it because I viewed the source (always interested to see what people are using to build front-end stuff).

edited: for clarity.

Unless you were dealing with a project that had dozens or hundreds of users/clients interested in tracking the status, it seems like sending an email would be a lot lower friction.