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.
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).
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.
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
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.
User receives password URL on an iPad, opens it, loads the destination login page, switches back to password tab, but it's gone forever because the iPad closed it to harvest memory.
User gets URL via webmail on Chrome, Chrome pre-fetches the URL. User closes Chrome because Starbucks is closing. When she finally visits the URL for the "first time" it's nuked.
Data shouldn't change on a GET for these very reasons.
Therefore, the secret shouldn't be obtained from a GET, but rather a POST. A button or jQuery.post on the 'shared' page, for example, that fetches and causes the deletion.
An interesting approach would be to delete the original data, but issue an ETag to leverage browser caching. If the original user rerequests the page while it's still in the browser's persistent cache, the server can simply return a 304 Not Modified, and the user still sees their data. Anyone else, though, is SOL.
You raise some great usecases. We have an option to require a password to view the secret but that doesn't directly solve the cases you bring up.
We're considering changing the basic UX to require a click to display the secret (the click will send a POST to retreive the contents). That will include a much more visible disclaimer that it's only available one time.
• loading starts a countdown timer, visible on screen: after that long, the message is destroyed. (In the meantime, an iPad re-download succeeds.)
• the reader sees a big button on the page which must be pressed to complete deletion (or to speed deletion, if the above timer is counting down).
* on initial load, the browser is given a unique cookie (or even decryption key); from then on, even if the message has an additional countdown 'grace period' (of seconds, days, or longer), only that one browser can reload (or decrypt) it.
Then the receiver reports to the sender that the link didn't work. The sender, not knowing if the password was compromised or if it was a situation you mentioned above, changes the password/revokes the key and generates a new one. This time, the receiver doesn't access it at closing time in Starbucks/doesn't switch tabs, and gets the new password correctly.
Unexpected behavior doesn't happen every time.
As an optimization, if you have a self hosted service of this sort that gives proper logs, you can probably verify that the link wasn't intercepted by looking at the source IP and comparing to what the user reports (if they're able to do that, if not, you fall back to assuming it was compromised), and if so, skip the revocation/regeneration procedure.
Interesting case of abuse: Send anonymous death threats as secrets. Would be hard to prove the message ever existed without server logs. Also, botnet c&c messages. WikiLeaks leaks! Damn, this is a useful tool.
Also, unfortunate for anyone trying to share the secret over the internet: if a repressive regime is sniffing traffic and looking for these URIs and grabs the contents first they can still discover the messages of dissidents before they get passed on.
A neat idea would be if you encoded the information on your server with a secret key, then put that key in the URL in addition to the unique identifier. This way you never store the information on your server. The secret key should never be put in your logs until the information is accessed and destroyed. If this policy is followed it would alleviate some fears of giving all my secrets to a third-party site.
In order for this to work, the key would have to be generated client-side and the secret encrypted client side. And you're still trusting that the site doesn't send the key when you submit the form.
While I think that this is a good idea, I hink that this would unfortunately result in URLs that would be much too long to be user-friendly - especially if we are talking about sending information to non-technical people.
There is no difference between storing plaintext on the server and storing encrypted text on the server if encryption key is (was) known to the server.
I also do something like this for http://jsonifier.com. I had users requesting that JSON pastes could be deleted after they were requested once. So, I know people find these kinds of features useful. I didn't think about building an entire tool around that one feature. Nice thinking!
They _should_ save everything that is sent with this service. They'll have a pretty good dataset to determine common passwords, etc. Then, they could use the data to help users pick better passwords. It's not an invasion of privacy if it's done anonymously, in aggregate, right!?
Love it. I came into a use case for something like this a while ago, and ended up using a combination of goo.gl (to know when the person had clicked), and text converted to an image (to stop simple copy and paste).
Maybe you could also incorporate the second part. It's obviously not a guarantee the information won't be copied, but if you know you're sending it to someone non-technical, it can be made extremely difficult.
Very neat concept. I like thinking about these new classes of sites/utilities - like one I made called http://shoutkey.com/ - which deal with useful temporary data instead of storing loads of data forever and ever.
I'm interested to know what data store you are using (just curious)?
I built something similar a few months ago: http://whisperpassword.com/ , it includes client-side encryption and email notification (including IP address and geolocation) of when the secret was disclosed.
For me sending sensitive information using a 3rd party service, no matter what the privacy policy is, is not an option.
On the other hand the amount of positive comments simply shows how bad user experience do the current solutions like GPG/PGP have and how easy it is for people to choose convenience over security, even on this forum.
Maybe it could work if you split the password up. Email someone the first half of the password, then tell them to append the second half from the link.
There is also FAQ: https://off-the-record.appspot.com/faq Any feedback is welcome. There is also secure pickup option on front page. Using it server logs won't show up even retrieved keys. Those could be potentially abused to fetch data from Google's backups.
The color scheme is a bit...extreme. To be honest the interface isn't nearly as straightforward, and in a small utility tool like this, that's what matters most.
I found strange that no one mentioned Privnote (https://privnote.com), a much older/popular service that does this but more securely since it generates URLs with keys in the fragment to encrypt the messages on client side (so that the plain message never hits the server).
fantastic. any application that has a password should also provide a method to generate a few one-time log-in urls that one could use from untrusted computers/environments. These uris could be issued with different privileges: e.g. for email, providing just access to the data younger than maybe two weeks.
No we don't keep any identifying information so we have no way to contact people. We only display a message on the private URI page to the effect of, "Message was received 30 minutes ago".
[+] [-] Xk|14 years ago|reply
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|14 years ago|reply
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|14 years ago|reply
[+] [-] zerostar07|14 years ago|reply
[+] [-] phren0logy|14 years ago|reply
[+] [-] mapgrep|14 years ago|reply
User gets URL via webmail on Chrome, Chrome pre-fetches the URL. User closes Chrome because Starbucks is closing. When she finally visits the URL for the "first time" it's nuked.
Etc. etc.
Unexpected behavior is unexpected.
[+] [-] joeyespo|14 years ago|reply
Therefore, the secret shouldn't be obtained from a GET, but rather a POST. A button or jQuery.post on the 'shared' page, for example, that fetches and causes the deletion.
I like this idea though.
[+] [-] stouset|14 years ago|reply
[+] [-] delano|14 years ago|reply
We're considering changing the basic UX to require a click to display the secret (the click will send a POST to retreive the contents). That will include a much more visible disclaimer that it's only available one time.
[+] [-] gojomo|14 years ago|reply
• loading starts a countdown timer, visible on screen: after that long, the message is destroyed. (In the meantime, an iPad re-download succeeds.)
• the reader sees a big button on the page which must be pressed to complete deletion (or to speed deletion, if the above timer is counting down).
* on initial load, the browser is given a unique cookie (or even decryption key); from then on, even if the message has an additional countdown 'grace period' (of seconds, days, or longer), only that one browser can reload (or decrypt) it.
[+] [-] mivok|14 years ago|reply
Unexpected behavior doesn't happen every time.
As an optimization, if you have a self hosted service of this sort that gives proper logs, you can probably verify that the link wasn't intercepted by looking at the source IP and comparing to what the user reports (if they're able to do that, if not, you fall back to assuming it was compromised), and if so, skip the revocation/regeneration procedure.
[+] [-] true_religion|14 years ago|reply
[+] [-] peterwwillis|14 years ago|reply
Also, unfortunate for anyone trying to share the secret over the internet: if a repressive regime is sniffing traffic and looking for these URIs and grabs the contents first they can still discover the messages of dissidents before they get passed on.
[+] [-] phogster|14 years ago|reply
[+] [-] delano|14 years ago|reply
[+] [-] rplnt|14 years ago|reply
[+] [-] Periodic|14 years ago|reply
[+] [-] mbreese|14 years ago|reply
While I think that this is a good idea, I hink that this would unfortunately result in URLs that would be much too long to be user-friendly - especially if we are talking about sending information to non-technical people.
[+] [-] fduran|14 years ago|reply
[+] [-] valyala|14 years ago|reply
[+] [-] spydum|14 years ago|reply
Also, pretty cool, if you refresh the private page, it'll tell you whether or not someone has picked up the shared secret. Nice.
[+] [-] delano|14 years ago|reply
It's built with Ruby and Redis behind thin and nginx.
[+] [-] mattlong|14 years ago|reply
[+] [-] delano|14 years ago|reply
[+] [-] Skywing|14 years ago|reply
[+] [-] delano|14 years ago|reply
[+] [-] joejohnson|14 years ago|reply
[+] [-] artursapek|14 years ago|reply
[+] [-] dazbradbury|14 years ago|reply
Maybe you could also incorporate the second part. It's obviously not a guarantee the information won't be copied, but if you know you're sending it to someone non-technical, it can be made extremely difficult.
Congrats on the product though.
[+] [-] delano|14 years ago|reply
[+] [-] jazzychad|14 years ago|reply
I'm interested to know what data store you are using (just curious)?
[+] [-] delano|14 years ago|reply
[+] [-] fduran|14 years ago|reply
[+] [-] cpenner461|14 years ago|reply
[+] [-] nigma|14 years ago|reply
On the other hand the amount of positive comments simply shows how bad user experience do the current solutions like GPG/PGP have and how easy it is for people to choose convenience over security, even on this forum.
[+] [-] delano|14 years ago|reply
That's tongue and cheek obviously b/c you do raise a good point. Do you have any examples we could base one on?
[+] [-] re_todd|14 years ago|reply
[+] [-] Sami_Lehtinen|14 years ago|reply
https://off-the-record.appspot.com/ or http://otr.dy.fi/
There is also FAQ: https://off-the-record.appspot.com/faq Any feedback is welcome. There is also secure pickup option on front page. Using it server logs won't show up even retrieved keys. Those could be potentially abused to fetch data from Google's backups.
[+] [-] __float|14 years ago|reply
[+] [-] cleverjake|14 years ago|reply
[+] [-] devongall|14 years ago|reply
[+] [-] desireco42|14 years ago|reply
Thanks for making it.
[+] [-] delano|14 years ago|reply
The reason we use it for passwords is because there's no way to know the application or the user account associated to it.
[+] [-] pablohoffman|14 years ago|reply
[+] [-] czam|14 years ago|reply
[+] [-] harisenbon|14 years ago|reply
Do you send confirmation mails, etc after the password is seen so that the sender knows the password got there?
[+] [-] delano|14 years ago|reply