Have not used it, just browsed the site for 40 seconds. What was interesting is that the /visual style/ jumped at me shouting "To be acquired by Dropbox". Anyone else have the same?
Not interested in being acquired or funded. Just built a little idea we've been sitting on for a while, and largely just to test out a few other projects in the field – things we're hoping to open source sometime soon.
I picked the Forward green, nwah picked the Torpedo blue – nothing more.
We actually use 1Password internally, but once or twice a week we were getting passwords emailed or IMed to us from clients and other people we worked with, so we added the secrets feature to Torpedo for those folks, to at least greatly reduce the chance of those passwords from falling into the wrong hands if someone's smartphone is stolen or email is hacked.
Also, the contents of secrets are encrypted with a randomly generated key, using AES 256 bit encryption, before being stored in our database. The key is then embedded in the share URL for the secret. We don't store the key nor the URL in our DB, so the only way to decrypt it is with the URL.
I don't want to be a downer, but - you signed up you and your staff without any details on how this is secured on the server?
It looks promising, but I'd want to see more information before I kept anything sensitive here - and by its nature, that's going to the only thing it would make sense to keep here.
I get: "Your Web Browser is Out of Date! Some features of this site (and many others) may appear broken. Your browser may also have serious security flaws. We recommend you upgrade to the latest version of a modern browser."
This is on Firefox 29.0.1, Mac OS X 10.9.3.
Even if whatever is causing that message is fixed, the language of the message really needs changing. I am running the latest version of a modern browser, and so are the other potential users/customers that you've redirected away from your site!
Hey guys, sorry about that. We just rolled that message out a day or two ago. The browser-detection is based on https://github.com/gabceb/jquery-browser-plugin but obviously needs some work. Working on a fix for that now.
>Quickly send passwords, credit card numbers, and other sensitive information safely. Your data is encrypted and can only be decrypted when viewed using your private link.
Am I missing something here? "Your private link" is what you pass around for others to download see the linked to document/data. Anyone who has the link (or is first to use it) has your password/sensitive data.
Nope you're not missing anything. The longer you wait to use the URL, the less secure it is. I could just generate a bunch of random URLs and wget them until I get something.
> The longer you wait to use the URL, the less secure it is.
Potentially true if you've chosen to upload with the 'one download' expiry time set, and then whomever you've shared the link with does not use it within 30 days (at which point it is expired & deleted). With the 'two days' option, the link does not become less secure than it was at generation because it (and the content) is deleted forever after 48 hours.
Take a look at the urls and do some calculation on how likely you are to actually get anything. It looks like 14 characters, alphanumeric with uppercase, which is about 10^25. Even if you can try a thousand urls per second, that would take you about 10^16 days to go through them all (that's a long time).
Or, if you want to calculate probabilities, assume that a billion urls are used (this is an astronomic overestimate). That's 10^9 urls. The chance of hitting one of those with a random guess is 0.00000000000014% (if I counted the 0s right). Not very likely.
Now if the url is observed in transit - that's a completely different thing. Just don't think that random guessing is going to reveal this. It's similar to people thinking you can guess your way to product keys for software (hint: you can't).
I don't think you're missing anything. That's the same idea I got.
There's no mention of authentication or encryption, whatsoever. Other than the obvious problems with putting plaintext secrets at a publicly-accessible URL, the whole security model seems to be "we promise to delete your stuff, trust us."
I find it really ironic that this is coming out right after the whole Snapchat scandal. (This is like Snapchat for documents.)
No, you're not missing anything. We built Torpedo to be a step-up from the way most of our clients and other people we worked with sent us stuff: files via Cloud links that sit around forever, and passwords in emails.
There are certainly more secure ways to send both of those things than Torpedo, but we wanted to make something that was more secure to send those things, while keeping it just as (or more) convenient.
We've got a few ideas that we're considering that'll offer more security, just trying to sort out how to keep it simple enough for our parents to use it.
I think you really need to look at what Citrix is doing with their Sharefile service. It's a secure cloud sharing service that has significant uptake in the professional services industries. It offers all of your features and more.
Files are not encrypted (but 'secrets' are). Files are actually uploaded directly to a private S3 bucket over HTTPS.
Secrets (text) are sent over HTTPS and encrypted with a randomly-generated key using AES 256 bit encryption before being stored in our DB. The key is embedded in the share URL for the secret. We don't store the key or the URL anywhere on our servers, so the only way to decrypt the secret's contents is if you have that URL.
I like the idea, however this seems like a feature DropBox could add easily. Unless you're giving me all the technical details of how it's encrypted, NSA can't get it or you will go down like LavaBit etc.. (not true with DropBox) I don't see the value in adding another app/service to the mix - For me, others might have a different take.
Torpedo isn't intended to replace DropBox. We just think about file sharing a little differently – we'd rather think of it the way sharing files over IM is supposed to work (which it doesn't), or the way AirDrop works.
We personally don't use DropBox, but a lot of people do. Hopefully DropBox will add the feature for those users, but I think they solve a different problem and it's probably not a priority to them.
We'll get an FAQ section up on the site with the questions from this thread, all good feedback.
Looks interesting, although more information on the encryption schemes used, how the key is stored/represented/generated would be nice given that the idea is to trust the service with my private data.
Hi Iburinoc, I'm one of the developers for Torpedo.
Files aren’t encrypted, but for secrets (i.e. text) the encryption happens server-side. We originally wanted to do client-side encryption (before heartbleed), but opted not to in order to keep the API simple.
When we get a secret, a random key is generated, that key is used to encrypt the secret using AES 256 bit encryption, the key is then mixed up with an identifier for the secret and that's included in the URL. We don't store the key itself anywhere on the server, nor do we store the URL (as it contains the key).
When request comes in to view/download a secret, we extract the decryption key and secret identifier from the URL, look up the secret, decrypt it using the key, then send the decrypted contents to the user (over HTTPS).
Ok, thanks for the reply. Do you guys have any plans to try client-side encryption at some point in the future and/or do file encryption as well? I have to agree with kenrikm to some degree, if the encryption and decryption is all done server side then we are really just trusting you not to cheat (Not saying you're untrustworthy, but it does seem to be a service built on security, which is a field in which I'd rather trust as few people as possible).
I like this service. I do it manually all the time when sharing passwords with coworkers and family. It would be nice to eliminate the trust issues by open sourcing the software though and allowing hosted versions. Could even charge for a mac app that connects to your hosted version of it.
Until we have more encryption details, I agree with yanatan that the only current value is in automating something I already do manually (deleting a link once the receiver has accessed the content).
Also agree with hexagonsun that sending passwords in plaintext is stupid. You could, however, send it via this channel, and the username via another (text message, IM, whatever). Still not super-great, but better than nothing, I suppose.
Good stuff. This actually solves a minor, but frequent real problem.
A couple of things. This needs a way to audit the downloads, i.e. to be able to see that the link was accessed by these IPs at this time (mind the time zones!). And perhaps also log and show cookies and user-agent.
Secondly, what's up with SignUp and Login? Just let people download the app and give them N uploads per month for free. Or just M lifetime uploads for free. Then ask to top up the credit, pay for a month or perhaps, shockingly, get a monthly subscription. All this signing up and logging in just muddles things and fits the app like a square peg in a round hole.
I think a lot of the commenters here so far have been too hard on this site.
No, it's not the solution to ever problem ever - it's ephemeral messaging for file sharing and trivial logins. It's SnapChat, applied to the Desktop in a way that doesn't revolve around teenagers sending porn back and forth.
Good luck, Torpedo devs. You found a niche, launched a product and are giving it a good shot. I'd love to see a status update sometime in the future.
I find it particularly amusing how many commenters are complaining about the lack of statement/explanation on the security model & encryption used behind the scenes--especially those comments suggesting one should hold out for such an explanation before using this service. Not because that isn't helpful information to have, but because it does not, in fact, provide the slightest shred of increased security, or additional reasons to trust this app (or any others).
I mean, the state of HN comments on things like Torpedo all tend to feature such a ring of comments warning everyone to not try something when there isn't a statement about security/encryption. And yet, such a statement is absolutely worthless for decision-making or increased trust. Anybody could write a statement promising all manner of security/encryption awesomeness all over the things they make. We could have a team put out an app that claims it has encrypted its own source code with AES256 4,096 times before deploying to servers and that everything you do is encrypted a billion times over, and it's just fucking words. Yeah, nobody would trust something that claimed that, I'm sure, cos it sounds ridiculous. But it's not inherently more or less trustable and/or secure based on the content alone.
If you're basing your decisions about who to trust on their words, you're using the wrong metric. "We delete everything, trust us" is no different from " the contents of secrets are encrypted with a randomly generated key, using AES 256 bit encryption, before being stored in our database. The key is then embedded in the share URL for the secret. We don't store the key nor the URL in our DB, so the only way to decrypt it is with the URL."[1]
None of this is to suggest you shouldn't trust the guys behind Torpedo and their app. I think you should. But even my words don't matter. No mere statement about security/encryption can be trusted based on the words alone. You can only actually trust something if you've been able to verify that it complies with the statement. And very few of the services anyone uses allow their users to obtain that level of verification.
> No HttpOnly flag or secure flag set on auth-token cookie
> Password reset doesn't require the old password
> Password policy requires only 6 characters
> No x-frame-options header (especially problematic with 3rd item)
> You're running sslstrip on port 10250
> You're MongoDB port is open to the internet
> No support for TLS 1.1 or 1.2
> Info is "encrypted" but keys are kept server side. You may not keep the URL after generation but it's still sitting in your server logs. Look at mega's use of strings after # for how to do client side only keys.
This is a great list. I wish I could vote it up more than once.
Do you maintain a full checklist publicly anywhere? I've seen some great checklists from security review teams in the past (iSec Partners, for example), but I don't know what their re-sharing policy is.
Thanks! Unfortunately I don't have a checklist of sorts. Most of what check for is just from habit and memory. I have a project I'm working on that will involve putting one together but that's still a few months out. If I remember I will shoot it over to you!
49 comments
[ 3.1 ms ] story [ 36.3 ms ] threadI picked the Forward green, nwah picked the Torpedo blue – nothing more.
We actually use 1Password internally, but once or twice a week we were getting passwords emailed or IMed to us from clients and other people we worked with, so we added the secrets feature to Torpedo for those folks, to at least greatly reduce the chance of those passwords from falling into the wrong hands if someone's smartphone is stolen or email is hacked.
Also, the contents of secrets are encrypted with a randomly generated key, using AES 256 bit encryption, before being stored in our database. The key is then embedded in the share URL for the secret. We don't store the key nor the URL in our DB, so the only way to decrypt it is with the URL.
That's cool, I wasn't really trying to knock the product. I just get a little paranoid :)
It looks promising, but I'd want to see more information before I kept anything sensitive here - and by its nature, that's going to the only thing it would make sense to keep here.
This is on Firefox 29.0.1, Mac OS X 10.9.3.
Even if whatever is causing that message is fixed, the language of the message really needs changing. I am running the latest version of a modern browser, and so are the other potential users/customers that you've redirected away from your site!
Am I missing something here? "Your private link" is what you pass around for others to download see the linked to document/data. Anyone who has the link (or is first to use it) has your password/sensitive data.
Potentially true if you've chosen to upload with the 'one download' expiry time set, and then whomever you've shared the link with does not use it within 30 days (at which point it is expired & deleted). With the 'two days' option, the link does not become less secure than it was at generation because it (and the content) is deleted forever after 48 hours.
Or, if you want to calculate probabilities, assume that a billion urls are used (this is an astronomic overestimate). That's 10^9 urls. The chance of hitting one of those with a random guess is 0.00000000000014% (if I counted the 0s right). Not very likely.
Now if the url is observed in transit - that's a completely different thing. Just don't think that random guessing is going to reveal this. It's similar to people thinking you can guess your way to product keys for software (hint: you can't).
There's no mention of authentication or encryption, whatsoever. Other than the obvious problems with putting plaintext secrets at a publicly-accessible URL, the whole security model seems to be "we promise to delete your stuff, trust us."
I find it really ironic that this is coming out right after the whole Snapchat scandal. (This is like Snapchat for documents.)
No, you're not missing anything. We built Torpedo to be a step-up from the way most of our clients and other people we worked with sent us stuff: files via Cloud links that sit around forever, and passwords in emails.
There are certainly more secure ways to send both of those things than Torpedo, but we wanted to make something that was more secure to send those things, while keeping it just as (or more) convenient.
We've got a few ideas that we're considering that'll offer more security, just trying to sort out how to keep it simple enough for our parents to use it.
Files are not encrypted (but 'secrets' are). Files are actually uploaded directly to a private S3 bucket over HTTPS.
Secrets (text) are sent over HTTPS and encrypted with a randomly-generated key using AES 256 bit encryption before being stored in our DB. The key is embedded in the share URL for the secret. We don't store the key or the URL anywhere on our servers, so the only way to decrypt the secret's contents is if you have that URL.
We personally don't use DropBox, but a lot of people do. Hopefully DropBox will add the feature for those users, but I think they solve a different problem and it's probably not a priority to them.
We'll get an FAQ section up on the site with the questions from this thread, all good feedback.
Files aren’t encrypted, but for secrets (i.e. text) the encryption happens server-side. We originally wanted to do client-side encryption (before heartbleed), but opted not to in order to keep the API simple.
When we get a secret, a random key is generated, that key is used to encrypt the secret using AES 256 bit encryption, the key is then mixed up with an identifier for the secret and that's included in the URL. We don't store the key itself anywhere on the server, nor do we store the URL (as it contains the key).
When request comes in to view/download a secret, we extract the decryption key and secret identifier from the URL, look up the secret, decrypt it using the key, then send the decrypted contents to the user (over HTTPS).
They do.
A couple of things. This needs a way to audit the downloads, i.e. to be able to see that the link was accessed by these IPs at this time (mind the time zones!). And perhaps also log and show cookies and user-agent.
Secondly, what's up with SignUp and Login? Just let people download the app and give them N uploads per month for free. Or just M lifetime uploads for free. Then ask to top up the credit, pay for a month or perhaps, shockingly, get a monthly subscription. All this signing up and logging in just muddles things and fits the app like a square peg in a round hole.
No, it's not the solution to ever problem ever - it's ephemeral messaging for file sharing and trivial logins. It's SnapChat, applied to the Desktop in a way that doesn't revolve around teenagers sending porn back and forth.
Good luck, Torpedo devs. You found a niche, launched a product and are giving it a good shot. I'd love to see a status update sometime in the future.
I mean, the state of HN comments on things like Torpedo all tend to feature such a ring of comments warning everyone to not try something when there isn't a statement about security/encryption. And yet, such a statement is absolutely worthless for decision-making or increased trust. Anybody could write a statement promising all manner of security/encryption awesomeness all over the things they make. We could have a team put out an app that claims it has encrypted its own source code with AES256 4,096 times before deploying to servers and that everything you do is encrypted a billion times over, and it's just fucking words. Yeah, nobody would trust something that claimed that, I'm sure, cos it sounds ridiculous. But it's not inherently more or less trustable and/or secure based on the content alone.
If you're basing your decisions about who to trust on their words, you're using the wrong metric. "We delete everything, trust us" is no different from " the contents of secrets are encrypted with a randomly generated key, using AES 256 bit encryption, before being stored in our database. The key is then embedded in the share URL for the secret. We don't store the key nor the URL in our DB, so the only way to decrypt it is with the URL."[1]
None of this is to suggest you shouldn't trust the guys behind Torpedo and their app. I think you should. But even my words don't matter. No mere statement about security/encryption can be trusted based on the words alone. You can only actually trust something if you've been able to verify that it complies with the statement. And very few of the services anyone uses allow their users to obtain that level of verification.
[1]: https://news.ycombinator.com/item?id=7769443
> No secure flag set on your session cookie
> No HttpOnly flag or secure flag set on auth-token cookie
> Password reset doesn't require the old password
> Password policy requires only 6 characters
> No x-frame-options header (especially problematic with 3rd item)
> You're running sslstrip on port 10250
> You're MongoDB port is open to the internet
> No support for TLS 1.1 or 1.2
> Info is "encrypted" but keys are kept server side. You may not keep the URL after generation but it's still sitting in your server logs. Look at mega's use of strings after # for how to do client side only keys.
Do you maintain a full checklist publicly anywhere? I've seen some great checklists from security review teams in the past (iSec Partners, for example), but I don't know what their re-sharing policy is.