[Xk]

Please don't use this for passwords. Security is very hard to get right.

Do they do a secure delete of the contents of the webpages? Who knows.

Do they have strong physical protection around the server? Who knows.

Do they run up to date software so the machine can't get taken over? Who knows.

Can you even trust them not to log all your passwords? Who knows.

This is an interesting service for some things, but I would never use it for sending passwords (or anything equally sensitive) back and forth.

Even if you let me "encrypt" the information before uploading it with a password, if this encryption is done in javascript sent by the server then as soon as the server is taken over you can't trust the encryption.

[mivok]

All of those objections boil down to not trusting a 3rd party service.

I wonder objections there are to running your own service of this type? This way you could guarantee the physical security, keep up with regular patches, manage your own logging, and securely delete the secrets to your satisfaction.

The only real objection I can think of is that writing software without security holes is hard. This applies to any security related software however, and the solution is to use 'proven' apps that have survived scrutiny. This type of app is pretty simple, which would ideally be relatively easy to audit.

In principle, a read-once URL that you can safely send via email seems to be a pretty efficient way of dealing with sending passwords or other keys without having to deal with GPG or similar. Just tell the client 'Click on this link, that's your password. This message will self destruct'. If it's intercepted, you can detect this, and change the password/revoke the key. I'm sure I'm missing something, but if not, it would be nice to have this become the standard way of distributing new passwords or keys for services rather than sending by email (for those services where you have an initial password generated for you).

[delano]

Nothing is entirely secure. We're two guys with no ulterior motives that take all reasonable precautions to keep the data safe. For most people that's not only enough, it's much better than having their passwords stored in their email archives and chat logs.

[trebor]

If the link is sent unencrypted a potential email relay or packet-sniffer could scan for the links related to your website and open it before the recipient. It would be easy to automate at any level. They wouldn't have context, sure, but they'd have whatever it is you wanted to send and your recipient wouldn't.

I don't think this is likely to happen.

Is your delete permanent, if not secure?

[brendoncrawford]

All of their http traffic redirects to https.

[trebor]

I didn't mean in reference to their site, but how the end-user transmits the link to a recipient.

[asdfaoeu]

The idea is that would be detectable because the recipient would no longer be able to view the actual link and the password can be changed again.

[brendoncrawford]

Perhaps you could go into detail about some of the security precautions which have been taken?

[zerostar07]

You're basically saying "don't use the internet". People who are gonna use it know what they re getting into. Plus the use case (a password to an unknown username of an unknown service) doesn't sound that dangerous to me

[phren0logy]

Well, maybe this isn't for you. Given the number of people who use "password" or "1234" to protect their accounts, your very valid concerns don't necessarily seem like show-stoppers. I don't expect any of the things you list above to be true for most other web services, either.

[gravitronic]

I highly doubt the typical user with password "1234" is going to go through the trouble of using this service. They would most likely email the password directly ("that's secure right?")

[Skywing]

You know what's funny? The company that I work for wrote a web app for a large company and we also host it for them. At one point in time, they requested a way for users to reset their passwords. We implemented it, but they never use it. They prefer to email me their passwords in plain-text. I think I've handled two of these types of emails today, alone!

[mseebach]

So what are you doing obliging them?

"I'm sorry, but we recently reviewed our security practices, and we've found this method of communicating passwords to be incompatible with our dedication to protecting the confidentiality and integrity of your business data. Please use the the password reset form at .. "

[drdaeman]

Just reply them with "oh, we now have an automated service for that" and a link to password reset form. They'll learn, eventually.