Secure, Web-based E-mail

Cal Godot writes "I've come across this interesting company, HUSMAIL.COM, that provides secure, encrypted, web-based email. They're pretty new, still working out a few kinks, and want people to take a look. (Bug reports should be sent to bugs@hushmail.com, by the way.) The URL is https://www.hushmail.com The whole thing works via a Java applet, and requires the latest-greatest web browsers. Source code is also availible. It's all built around public/private key encryption, using a 1024-bit Diffie-Helman scheme. "

Comments

Here's the difference

[Anonymous Coward]

So what's the difference between a brute-force attack and a dictionary attack?

A brute force attack is when you attempt to exhaust the entire solution space. Example: If you were to brute force a typical 4 digit PIN, you would try 0000, 0001, 0002, ..., 9998, 9999 since you know it HAS to be one of those 10,000 possibilities.

A dictionary attack is when you take a long list of common words and check if any of them works as the password.

Yes, they are still around

[Anonymous Coward]

Are chains of Anonymous Remailers still available?

Oh my, yes! Go here for lots of up-to-the-minute stats:
http://anon.efga.org/~rlist/
(As an aside, it really irritates me when people think remailers don't exit anymore because anon.penet.fi went away a long time ago.)

Vunerabilities

[Matts]

The exploits in all the other web based email systems (particularly hotmail, although I suspect they are just targeted because they are big) have been based on browser bugs, and Javascript deficiencies. What's to say that something running as Java won't suffer from similar problems? I know there's the sandbox there, but will that be enough (i.e. there might be bugs in their server configuration or any other possible point of entry)? And do enough people care?

For me, I don't care about the security of my email, just that I can get it 24/7 and quickly (which is why I dumped hotmail for joymail). I honestly don't think that many people will care enough to use Java for their email. Especially not considering how slow it is. Still, I might just create an account, just for a laugh...

Matt.


perl -e 'print scalar reverse q(\)-: ,hacker Perl another Just)'

Diffie-Hellman insecure

[jnik]

As I recall, Diffie-Hellman has a rather serious vulnerability in it, rendering it far less secure than it was supposed to be.

Short story is that the DH encryption problem really isn't the same as the knapsack problem--some unimportant simplifications turned out to be important.

Hummm.....

[A well known coward]

I tried to set-up an account just to see what they're all about. For a company that is so interested in the users' privicy, they sure ask you a lot of personal questions. For example, why would they need to know people's income?

BTW, what are the chances of /. running a email redirecting service? I wouldn't mind paying 50 bucks or so to support /. while getting an "@slashdot.org" address. :)

They are providing source

[edgy]

Some people here posted about not trusting the Java app to be secure. Apparently, they've already thought of that. They seem to "get it" as far as security. Here's an excerpt from the FAQ page:


How can it be proved that the HushMail system is actually secure?

Simply put, the most important aspect of any computer security system is the ability for lots people to test it as well as possible. The Java Source Code of HushMail is available to everyone, free. Security experts worldwide have the unrestricted ability to try and find any security holes. We are completely open to this form of peer review, as we believe this makes for the strongest systems available today. Our source code is open to you. Please view it at your leisure. It can be found at http://www.cypherpunks.ai/~hush/hush-src.102.zip. In addition, a description of the functionality of the system is available here.


I have at least one reason I would use something like this: If I want an anonymous account that can't be traced back to me in case I don't want my job or people I know knowing it's me. This is an easy way of doing it without needing an anonymous remailer.

For anyone who requires Web-based email

[jsm]

you'd think that people who cared enough about their privacy to want to strong-encrypt their email would just install PGP on their local system and be done with it, rather than trusting a third party to take care of the encryption for them.

Not everyone has a local system to install PGP onto.

Who's this for? The same crowd that uses Yahoo mail, hotmail, etc. Joke all you want, but there are legitimate uses. Notably, for people who can't afford to own a computer and must do all online activity through browsers at libraries, schools, cafes, etc. You'd be surprised how many homeless people have an active online presence.

Granted, they'll never be secure as long as they trust this third party to handle their encryption. But it's a couple steps better than unencrypted Web-based email.

I'm really glad this is happening. With luck, all the other Web-based email services will add encryption too, at least in the mail that gets sent out. The sooner we have a critical mass of the email world using encryption, the sooner it will be considered standard.

Looks sketchy

[cjsnell]

Here's an excerpt their WHOIS db entry:

Domain Name: HUSHMAIL.COM

Administrative Contact:
Hush Communications, Admin acct. (HC507-ORG) hushadmn@HOTMAIL.COM
(512)-441-0205
Fax- (512)-441-8052
Technical Contact, Zone Contact:
Hush Communications, Tech acct. (HC508-ORG) hushtech@YAHOO.COM
(512)-441-0205
Fax- (512)-441-8052
Billing Contact:
Hush Communications, Admin acct. (HC507-ORG) hushadmn@HOTMAIL.COM
(512)-441-0205
Fax- (512)-441-8052


Note the Hotmail and Yahoo accounts listed.

Re:Java - no thank you.

[crisper]

You know, the people who often write those little tid bits on the web page aren't usually the "security experts". They are most likely marketing people with no in depth understanding of the technology. Would you hold a job as a security consultant writing these things?? I dont think so, so let it be, you cant always be 100% correct, at least they let people know that they are somewhat protected from an attempt to crack their password. Most people do not know the difference between a brute-force attack and a dictionary attack, and they never will, nor will they ever need to, they just want to know they are protected, eve just a little bit

The difference. Pay attention this time

[lazarusL]

Example time. You have a password, say it's 8 characters long. For the sake of simplicity-of-example, let's say all characters must be alphabetic and upper-case. (Obviously, this is a very insecure system, but it's only for example.)

Let's say you are lame, and choose P-A-S-S-W-O-R-D.

If a cracker attempts to break your password by manually trying each word in a dictionary, this could take a long time, but would certainly succeed. If the same cracker automates the process by trying each word in a text file such as /usr/dict/words, it would take a lot less time, and also be certain to succeed.

The above is known as a "dictionary attack" for obvious reasons. BTW, the more effective variations include subverting such common lame attempts to "improve" ths security of a password by changing letters to numbers (password -> passw0rd) by including these variants in the text file (or a tiny algorithm) so don't rely upon such.

Let's say you instead chose N-X-B-Q-R-K-Y-V as your password.

A dictionary attack would not succeed against such a password. Not only is N-X-B-Q-R-K-Y-V not to be found in Merriam-Webster, but it is not contained in any of the enhanced lists of "words" that are available for password cracking.

Can a cracker defeat such a password? Certainly. Manually, it would require a ridiculous amount of typing (or phenomenal luck.) But how about an automated solution?

It is trivial to write a routine to test A-A-A-A-A-A-A-A, then A-A-A-A-A-A-A-B, then A-A-A-A-A-A-A-C, and so on (which is known as a "brute force" attack, btw.) Writing the routine isn't the issue, running it is. The security of a password is based solely upon *how*long* it takes an attacker to guess it, right?

A brute force attack, by definition, will always succeed, if carried out to completion, since, by definition, it tests every possible combination of characters. A dictionary attack will only succeed against "common" passwords (such as those containing only "words" (or variants) and their combinations (such as TASTY-BUG.)) The advantage of a dictionary attack over a brute force attack is that it takes a lot less time to run, and is likely to be successful much sooner, since most people, sadly enough, are either lazy or uneducated or perhaps both, and choose very insecure passwords/passphrases.

Now, let's leave the world of this example, and enter the world of more security. Passwords would not be limited to just A through Z. We could add 0 through 9. Each additional possible character would increase the number of potential passwords exponentially, since each of the eight positions could now contain that character. We could then remove the case sensitivity requirement and add a through z. We could then add a number of "special characters." To add each of these to the above brute force routine would also be trivial, taking well under a minute. To actually run that routine through to completion however would become more and more time-consuming, to the point of being "unattainable" using (ahem) "today's technology" (especially if we removed the eight-character restriction.) For more on this principle, consult a math text book regarding "permutations." :-)

Password "security" == Estimated-time-to-crack-it. A "good" password will protect longer than the data inside needs protection. "Foever" requires more than just a password/passphrase.

Java - no thank you.

[Skinka]

My browser is unstable enough as it is.

btw check what they say about passphrases: Note that the passphrase in our example is not a common phrase, such as a quote, a song lyric, or a general exclamation that could be compromised via hacker "brute-force" attacks.

Just lost my faith in these guys, real security experts should know the difference between brute-force and dictionary attacks.

who's this for, again?

[th0m]

you'd think that people who cared enough about their privacy to want to strong-encrypt their email would just install PGP on their local system and be done with it, rather than trusting a third party to take care of the encryption for them.

i'm sure the java solution performs the encryption locally and never sends anything plaintext to the hushmail server (otherwise what would be the point) but it seems to be more hassle than it's worth.

i'm not saying this isn't useful; i'm just curious as to exactly what demographic they're aiming at. people who are already anal about their privacy will know how to do their own secure email; and people who don't go crazy about privacy and/or don't know how to use PGP will probably just go and use a more straightforward webmail service.

Standards

[jkdufair]

I set up an account, only to find that you can only encrypt to other husmail [sic] accounts. What about standards, folks? PGP, S/MIME? I really don't think we need another "patent pending" encryption system. I'm pleased to see they're using blowfish, but why not use PGP then? Doesn't PGP6 support blowfish?

Jason Dufair
"Those who know don't have the words to tell

Not really a secure e-mail...

[MeanGene]

Well, it looks more like a commodity web-based e-mail, but running on a SSL-enabled server. Their FAQ plainly states that only e-mail sent to another hushmail user is secure. Duh...

PGP all the way!

Anonymity and encryption are different

[Kaa]

Anonymity doesn't have much to do with encryption. Just because they provide the encryption service does not mean that they don't keep logs of connections. If they do, a message, even encrypted, can be traced back to you quite easily.
Until recently the simple way to be anonymous was to set up a hotmail account through www.anonymizer.com and access it only through the anonymizer. Unfortunately, this is broken now, although I'm sure it's easy to find a free e-mail service that works through the anonymizer.

If you are interested in practical anonymity, check out www.zeroknowledge.com. Of course, there is a bunch of other resources on the net.

Kaa