|
Tokens and security
I question the "brilliance" of the token idea. Think about how easy it is to subvert this. The "token" is sent in cleartext email, and can be intercepted and redeemed by anybody. Unless you're encrypting your email with a key only the recipient knows (PGP comes to mind), there's no way to control who gets your token and who redeems it.
This wouldn't be so bad if Cleo didn't make security claims like this one, making people think this is somehow more secure than sending the file directly as an attachment:
"Secure. Files are encrypted with 128-bit AES encryption prior to transfer."
Great, but of course what they don't say right there is that the key is sent in the token. Without authentication, encryption is pretty meaningless, IMHO.
Besides this, think about how much trust you are placing in software that exposes an HTTP listener from your machine. Hope you trust these guys *a lot* before you install their token creator software on your machine.
Keith
http://www.develop.com/kbrown
Keith Brown
Friday, October 24, 2003
Keith, maybe they worded their promotional material in a misleading way, and if that's the source of the complaint then fair enough. But I think they've done the best they could with their technology.
This software is going to rely on network effect to make it take off. It only really becomes a time/hassel saver if a critical mass of your contacts also uses it. So they need to have it adopted as widely as possible as quickly as possible or it's not worth doing.
So of course they've made it free to recieve tokens, they've made it as easy as possible for the recipient to download and install the software they need to redeem the tokens they recieve, etc, etc. But in allowing tokens to be sent via email they've also leveraged the fact that everyone already has it and doesn't need to sign up for some parallel service before they can even get a token.
I think the answer is for them to just suggest encrypting the email containing the token if you want to send a file securely.
My biggest complaint is that they are trying to get people to pay individually, one at a time, to lay down a new internet standard. I don't think it's going to be adopted quickly enough to catch on if people have to pay to create tokens. What I think is going to happen is that some nerd is going to log into sourceforge, make a free, decentralized clone and the technology is going to get away from Creo within a few months. They may as well offer it to the internet free, as a gift, and make some political mileage out of it.
Colin Fletcher
Friday, October 24, 2003
The system is no less secure than transferring files via email (or, for that matter, FTP, where the username and password is sent in plaintext).
Without the email, J. Random Hacker can't just download the files from your machine and use them. They'd have to hijack the email, which is somewhat more difficult.
Tim Sullivan
Friday, October 24, 2003
Both HTTP and FTP can be protected with SSL, which would include protecting the credentials.
Brad Wilson (dotnetguy.techieswithcats.com)
Friday, October 24, 2003
Sure, FTP and HTTP _CAN_ be secured. But generally are not, and most people who are using it for general file transfers around the office are not using it securely. And guaranteed very few people who are flinging files around in email are doing anything securely either.
Keep in mind the scope of the problem that tokens are trying to solve: replace emailing big files.
Tim Sullivan
Friday, October 24, 2003
Hmm. I guess the next level then would be everyone has one of those token readers / downloaders already installed, and their PGP credentials are public.
Then when you're sending the email in PGP you simply check off who can open it, or it's assumed anyone in your TO, CC, or BCC can open it unless you state otherwise.
Then when they come to your computer to retreive the file, it's either encrypted so that only they can decrypt it with their private key, or a password is sent to each of them encrypted via PGP. Probably a long string of nonsense characters they have to enter like a registration code to retreive the file.
The former has sort of added security, the latter allows the sending of just that string of characters to anyone to retreive the file.
Either way, once the 2nd party has the file, they can do whatever they want with it.
Which reminds me, has anyone successfully integrate PGP into an email program in a way that isn't clumsy yet?
www.MarkTAW.com
Saturday, October 25, 2003
Mark:
I wouldn't be suprised at all if this is the direction they intend to take it if it takes off. It's the logical next step, for sure.
Tim Sullivan
Saturday, October 25, 2003
*yawn*
This service is "great" as long as:
The sender wants to leave their computer on running 24x7.
The company sponsoring this scheme doesn't go out of business, shut down the service, start charging for the service, or otherwise change the protocol.
I realize that the purpose is for one-off email file transfers, not for maintaining a body of data on a server to be downloaded at random. But it just seems needless and excessive and gives control of your data to yet another third party.
Bored Bystander
Saturday, October 25, 2003
I don’t think a lot of people want to setup their own web server or ftp site anyway.
However, Kazza and any of the peer to peer file swapping services are free, work through most fire walls, and are a very good way to allow people to grab some files from your computer. The price of these file sharing programs is also right!
The problem with ftp, or even Kazza is that I don’t want to simply share a BUNCH of files. I don’t want the wrong people grabbing a new version of my software for example.
The same goes for all kinds of documents, I can’t just throw them into a dir, and have a bunch of people grabbing those documents. Often, some of the large documents are intended only for a select few.
This system appears to utilizes the peer to peer ability of computers to transfer a file, and that is a great idea.
For supporting a user base, and sending software updates, this seems like a very good idea, certainly better then email. I finding a lot of companies are not even accept .zip files via email anymore. With all this virus stuff, a lot admin don’t allow much in the way of attachments anymore. Also, I do encounter size limitations a lot also.
Besides, why put such heavy loads on a mail server anyway?
This whole idea seems like a good idea all in all. The IM programs are quite good at file transfers, but they seem to have a lot of trouble with fire walls. If this application works well through fire walls, it does solve some problems, and the people don’t have to setup a server to do this.
Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn
Albert D. Kallal
Saturday, October 25, 2003
How about this, instead of this company's "tokens" concept: a modified SMTP server.
You'd specify this (alternate?) SMTP server in your email client's options.
The specially modified SMTP server could do the following when an email containing file attachments is sent:
Strip each attachment.
Decode each stripped attachment back into a file.
Copy the file into FTP space dedicated to the person sending the email.
Replace the attachment in the body of message with a link to the FTP space and the file that was saved by the SMTP server. (for extra, non-hard security, it could create a username and password for the file which are also embedded in the email text.)
The recipient would see an ordinary, classical file link and would click and download it. No downloads of special purpose P2P software.
While not shrouded in encryption security, a function like this could be a customization of common free email servers such as QMail. It would require some configuration to fit the server on which it was installed, but once in place, it would perform essentially the same service as what the "token" concept implies.
One last thing. Many end users struggle to have just enough clue to understand what a file embedded in a message even means. The extra level of indirection of a P2P program to do what used to be 'included' in the email client makes this stuff mainly a geek toy.
Bored Bystander
Saturday, October 25, 2003
Bored Bystander, this still doesn't solve the problem of the 500 mb Photoshop file and the 10 gigabyte mail server shared between 100 employees. It just puts the 500 mb file on the sender's mail server rather than the receiver's.
Much like Nullsoft's "Waste" (q.v.) this was probably developed as an internal product so the Creo folks could share files back and forth.
====
http://www.nullsoft.com/free/waste/
http://sourceforge.net/projects/waste/
etc.
www.MarkTAW.com
Saturday, October 25, 2003
 Recent Topics
Fog Creek Home
|
