I got a response from Matt at Whisperbot regarding my post Whisperbot - No thanks, I'll use e-mail.
You can read the reply here, it's the third reply on the post
Regarding the previous post, I would like to clarify that I have no interest to attack the Whisperbot service, and I hope that their team will use my analysis to improve on the service.
Here is a deeper analysis of my points with references from the Whisperbot reply
1. Message transport in cleartext
Actually, there is an https secure version at https://www.whisperbot.com
- Although there is a https site, the default service is on a cleartext http site. And most users will always use the default service without even bothering to look for the https variant. Whisperbot is offering confidentiality, so a default encrypted channel is a must.
2. Message is stored on Whisperbot servers with unspecified and not very reliable security measures
Yes, its in a database, of course. But, I rebut that its not secure - I'll happily share with you the database content and I'll let you see if you can decrypt it. Everything - from message to email address is encrypted - and we're not talking md5 here ;-)
- First, MD5 is a hashing, not an encryption algorithm. And since it's nearly non-reversible for long messages (the rainbow tables will be enormous) you can't use it. The whisperbot service obviously uses reversible encryption, and I have no intention on disputing the strength of the encryption (although they won't publish the algorithm). What I am disputing is the fact that the whisperbot servers also hold the encryption/decryption keys, since the servers present the message in cleartext to the recipient. So, the first risk are disgruntled administrators who can leak or steal the key database. Also, as an attacker, I would direct my efforts at tapping/stealing the key database. Just publishing the key database without any actual stolen message will be annihilating to the whisperbot service, since it is based on trust of the users.
3. Security is based on obscurity
There is an option to use a passphrase - so, even if someone else gets the link, they can't read the message without the passphrase.
- I stand corrected as long as Whisperbot MANDATES a passphrase on every message. As long as the service maintains the current solution, it's still just using security by obscurity.
4. Message retention cannot be controlled
Agreed with the need for a delete button of sorts - right now, we just trim the message after it's been read and stored for a period of time.
- Instead of a delete button, i would suggest an automatic erase after the presentation of the message - this will reduce the database capacity requirement but will increase the I/O load on the database. Whisperbot will probably be going with the 'pruning' option first at times when the servers are at minimum load. While this option is good for the servers, it's not as secure as an auto-destruct method.
Talkback and comments are most welcome
Whisperbot - No thanks, I'll use e-mail.