Secure webmail

Matches

Lavaboom provides secure mail. (Computer World Article)

IDG News Service - A new webmail service called Lavaboom promises to provide easy-to-use email encryption without ever learning its users' private encryption keys or message contents.

"Key handling is a very sensitive issue," Lavaboom said in a technical FAQ section on its website. "We let you download your keypair during registration. This is to ensure that your key remains in your possession."

Lavaboom's JavaScript code and the user's private key is stored in the browser's cache, which leads to some limitations. For one, this ties the key to a particular browser and makes accessing the account possible only from the device where that browser is installed.

"Never clear your cache from Lavaboom," the email service provider warns on its website. "We do not offer password recovery, since we can't! Once you flush your private key, all your data stays encrypted until you somehow rediscover your private key. We will not provide you with any refunds if you lose your private key."

And musn't forget:
Lavaboom claims that it doesn't know the exact locations of its servers and doesn't have physical access to them, making it more difficult to respond to government requests for data.

I feel much safer now.

morbiuswilters

Sounds like an NSA phishing expedition..

"Say, Mohammed, we need email accounts so we can coördinate our attack on the Great Satan."

"Excellent point, Faisal. Let us use this new 'Lavaboom'--they don't even know where their servers are, so they should be safe from prying eyes!"

A few minutes pass..

BOOM!

"My word, Mohammed, what was that?"

"Egad! It appears the next-door orphanage-hospital for children with disproportionately-large, adorable eyes has been destroyed by a drone!"

RaceProUK

@Matches said:

Lavaboom's JavaScript code and the user's private key is stored in the browser's cache

Works brilliantly for those who set their browser to clear the cache when it's closed down.

Buttembly_Coder

@Matches said:

Lavaboom's JavaScript code and the user's private key is stored in the browser's cache, which is regularly reported to Microsoft, Google, or directly to the NSA anyways.

morbiuswilters

@RaceProUK said:

@Matches said:
Lavaboom's JavaScript code and the user's private key is stored in the browser's cache
Works brilliantly for those who set their browser to clear the cache when it's closed down.

The really amazing thing is they're doing the crypto in JS. Have you ever tried that? Just doing an MD5 on a few dozen MB of data will cause the browser to explode. I can't even imagine how crap-tastic it is at doing real crypto.

Anyway, seems like having email that's encrypted client-side and which doesn't need special software to use would be cool, but why store the key in the browser cache (I'm assuming they mean "cookie"..)? You'd be way better off having them enter a password and generate a key based on that. Then it's not tied to a single computer, doesn't store secure keys in the cache and all you need is the password to jam.

locallunatic

@morbiuswilters said:

Anyway, seems like having email that's encrypted client-side and which doesn't need special software to use would be cool, but why store the key in the browser cache (I'm assuming they mean "cookie"..)? You'd be way better off having them enter a password and generate a key based on that. Then it's not tied to a single computer, doesn't store secure keys in the cache and all you need is the password to jam.

How would you tie password to key without the provider having a copy there of (I guess if the key is generated from a password would work but I've no idea how to generate a valid two key set up from one)?

Lorne Kates

Oh, come on. We're being way to hard on an obviously cobbled-together service being provided for free.

@Matches said:

We will not provide you with any refunds if you lose your private key.

Well, ferk.

A free service that doesn't give refunds!

Buttembly_Coder

@El_Heffe said:

A free tiered-subscription service with a free tier that doesn't give refunds!

HardwareGeek

@Matches said:

the user's private key is stored in the browser's cache

I know I'm not the first to point out the stupidity of this, but I can't even comprehend something thinking this is a good idea. A cache is, by ordinary usage if not actual definition, temporary storage.

morbiuswilters

@locallunatic said:

@morbiuswilters said:
Anyway, seems like having email that's encrypted client-side and which doesn't need special software to use would be cool, but why store the key in the browser cache (I'm assuming they mean "cookie"..)? You'd be way better off having them enter a password and generate a key based on that. Then it's not tied to a single computer, doesn't store secure keys in the cache and all you need is the password to jam.

How would you tie password to key without the provider having a copy there of (I guess if the key is generated from a password would work but I've no idea how to generate a valid two key set up from one)?

Yeah, just generate it from the password. That's actually how most systems that encrypt data using a user-supplied password work, because all of crypto algorithms require a fixed-length key. So say you need a 128-byte key for encryption, you sha1 the user-supplied password and then take the first 128 bytes and use that as your key.

morbiuswilters

@HardwareGeek said:

@Matches said:
the user's private key is stored in the browser's cache
I know I'm not the first to point out the stupidity of this, but I can't even comprehend something thinking this is a good idea. A cache is, by ordinary usage if not actual definition, temporary storage.

The funny thing is, this only makes the service seem even more skeevy. Either they just suck at web technology, or else they intend for you to use your address a couple of times and then forget about it (i.e. like a burner, but for email). If it's the latter case, then clearly this is mostly meant for criminals.

I do love the defense of "We don't know where our servers are located!" Sure, you may not, but I bet the NSA and FBI can find them. And it's not like it would stand up in court, either. "I don't know where the servers are located, your honor." "Okay, give the court your provider and account number and we'll find out from them." "Shit, why did I think that would work..?"

dkf

@HardwareGeek said:

@Matches said:
the user's private key is stored in the browser's cache
I know I'm not the first to point out the stupidity of this, but I can't even comprehend something thinking this is a good idea. A cache is, by ordinary usage if not actual definition, temporary storage.

A local database would be far saner, and I think nearly all modern browsers support that sort of thing now.

morbiuswilters

@dkf said:

@HardwareGeek said:
@Matches said:
the user's private key is stored in the browser's cache
I know I'm not the first to point out the stupidity of this, but I can't even comprehend something thinking this is a good idea. A cache is, by ordinary usage if not actual definition, temporary storage.
A local database would be far saner, and I think nearly all modern browsers support that sort of thing now.

Well, that's often temporary, too. They probably are using a local DB or cookies, not the literal browser object cache (which would be.. insane.)

HardwareGeek

@morbiuswilters said:

@dkf said:
@HardwareGeek said:
@Matches said:
the user's private key is stored in the browser's cache
I know I'm not the first to point out the stupidity of this, but I can't even comprehend something thinking this is a good idea. A cache is, by ordinary usage if not actual definition, temporary storage.
A local database would be far saner, and I think nearly all modern browsers support that sort of thing now.

Well, that's often temporary, too. They probably are using a local DB or cookies, not the literal browser object cache (which would be.. insane.)

Agreed, but...@Computerworld said:

"Never clear your cache from Lavaboom," the email service provider warns on its website.

Matches

Morbs, It's fine.

"If we should become scrutinized by law enforcement we rely on a severe public outcry, since we are under jurisdiction of the German law and the best privacy laws in the world," the email service provider says on its website. "If we should ever be forced by the BSI or the BND [Germany's information security and foreign intelligence agencies] to give up all our data, rest assured that we do have something in place that will destroy our hard disks in a matter of minutes and turn them into little more than coasters."

HardwareGeek

@moribuswilters said:

The funny thing is, this only makes the service seem even more skeevy. Either they just suck at web technology, or else they intend for you to use your address a couple of times and then forget about it (i.e. like a burner, but for email). If it's the latter case, then clearly this is mostly meant for criminals.

@Matches said:

"If we should ever be forced by the BSI or the BND [Germany's information security and foreign intelligence agencies] to give up all our data, rest assured that we do have something in place that will destroy our hard disks in a matter of minutes and turn them into little more than coasters."

Funny, that doesn't make the service seem less skeevy. "To prevent law enforcement from obtaining, through legitimate due process, access to data, we will irrecoverably destroy all the data of all our users."

morbiuswilters

@HardwareGeek said:

@moribuswilters said:
The funny thing is, this only makes the service seem even more skeevy. Either they just suck at web technology, or else they intend for you to use your address a couple of times and then forget about it (i.e. like a burner, but for email). If it's the latter case, then clearly this is mostly meant for criminals.
@Matches said:
"If we should ever be forced by the BSI or the BND [Germany's information security and foreign intelligence agencies] to give up all our data, rest assured that we do have something in place that will destroy our hard disks in a matter of minutes and turn them into little more than coasters."
Funny, that doesn't make the service seem less skeevy. "To prevent law enforcement from obtaining, through legitimate due process, access to data, we will irrecoverably destroy all the data of all our users."

Yeah, there's an easier way to phrase that: "Rest assured, we're willing to go to prison for a very long time for obstructing justice." Now do you trust them?

I'd also like to reiterate that their privacy laws mean jack shit. If they want the data, intelligence agencies will get the data and the retards running this company won't even know it happened. And that "destroy the hard disks" thing is so B.S. Do they not understand how SWAT teams (or the German equivalent) work? Do you want to be the lowly sysadmin who's tasked with making a dash for "the button" to destroy all the drives when he's got six guns trained on him? Fucking idiots..

Lorne Kates

@Matches said:

we do have something in place that will destroy our hard disks in a matter of minutes

What sort of shitty "something" are they using that takes MINUTES to destroy a hard drive? Wow, the layers upon layers of fail are astounding.

morbiuswilters

@Lorne Kates said:

@Matches said:
we do have something in place that will destroy our hard disks in a matter of minutes

What sort of shitty "something" are they using that takes MINUTES to destroy a hard drive? Wow, the layers upon layers of fail are astounding.

Midget with a ball-peen hammer locked in the server cabinet?

Ben L.

@morbiuswilters said:

@locallunatic said:
@morbiuswilters said:
Anyway, seems like having email that's encrypted client-side and which doesn't need special software to use would be cool, but why store the key in the browser cache (I'm assuming they mean "cookie"..)? You'd be way better off having them enter a password and generate a key based on that. Then it's not tied to a single computer, doesn't store secure keys in the cache and all you need is the password to jam.

How would you tie password to key without the provider having a copy there of (I guess if the key is generated from a password would work but I've no idea how to generate a valid two key set up from one)?

Yeah, just generate it from the password. That's actually how most systems that encrypt data using a user-supplied password work, because all of crypto algorithms require a fixed-length key. So say you need a 128-byte key for encryption, you sha1 the user-supplied password and then take the first 128 bytes and use that as your key.

Ok, which of the 20 bytes are we taking for our 128 byte key?

Ben L.

Qe5xBZlsvsXFr4ZwZwLcT6voSgAdtsvtzk0w8Jf/Km4lNS/auL3/+B1bfU8K7xL6PJXZzZTQRxSI
ZarsnPHzUDPavMJkONuDIMXOa2vhWTbTA40pcgsjAxktzqQFFB8z1GxrbffdQ24yIJQ8QN9swwvs
an4wV+bgCx7Kj0q5DbtL1Jg8brau64NvXa8gOrh9IWciqzi7KnNkiJxk2m3n5bGD5jqLe8E9FjW3
HLslNZvwBSD1TwZrSjVgBY4Ab85/FmaL2sLMKVh5lkwxZAkRHaqCzgLnY4lieVon6FZcxOm4fRaf
pDkL1L4c+cowP74ej4/xf5JcPnkj+ifBZmDfDFKAalebfJh1WCQMRieGPBE5jceiv0nVZHVFLbHN
53ixpIxEDcdZRNbZ6vuOEtDAIsM2S6Y8wlvW2tTTuHneEli+NKDSYR0eZSwh2CCgqwZVNmANUMS4
zJu7nz95RRrKMWSnHU41a7iPfffAMR0nR9z+1ApxoWxa0ph4FzGpg9YnnPHNV5c9sgQadA2ndvcm
IZOPXcizlhq1m9pfdAMxc/36zeNk4PKpgIKtaiESSBwM8V2xXQOe8OT/b07ODLTyjyqTY2VjEAVT
y59j2WN56sZ+BDNJu2+LiHLDC8Np2i1k61w+2ZV3rj3F55sF+zYGMkXMbMIrXoqYAV5yo/5nfie5
580s1IpTKOMoq09UsQaq7risiALXjqUwHPdYT7nEcUwWvAVDnMUSqfSDK/i+UX2RL7VTisieytAu
4bhiyjwOJSuIKWDBpChJcQLR6hlKTsxnoAqnsZgjak1zYHbLuBre7JQ5fL84l7oTj857ri8v9yN1
ciqwMri8f/cwWuJqO2bQ6Si936lrXOEzd19NL1liZP4ajZ/BVJmhtMksrBt6zeQepdK5C0siiac0
qrBt+bHMf/+Qzlp3dPdMlozaMYpHYXXG0x1yjKFKVlvMgs7GCrspGGIvQBbR+LkV5yeLdqKWFGkq
IWMOTV68McnCcxIODPgDR97AGwSJMxkVwkZdRQ1whUkdSPVggivMexK3kG9eZog28zA8oYlJ2MKz
bRcMpL6EragauEZkfnus5rE5y1cKZapog0M+4c9r31pdxroH427yV/P97kXlKqXsTLTvfT09yg0N
wr0kfBwcl5Xuq4FM6jEAVcAsOIqE7WosF1y5myBIKnRuDl63rfoSQdyspVWZBjZ9udPyAWkhYp7s
BfaYKrVlSNERJ9lf0ObTvJJqSLXnvte+JUT8Ez3qBRiKMceo0d66P8vxNuRlimvZkMnxGREXUodB
QT35/DhdzTvSpgGEKfMaDVZRmFwoPYb1QWlNtdTK4DziwVytcba4BG7w/kJ2Ql4KlT0kZNUemQ==

This is some very important text, encrypted with a key that is in your browser's cache.

morbiuswilters

@Ben L. said:

@morbiuswilters said:
@locallunatic said:
@morbiuswilters said:
Anyway, seems like having email that's encrypted client-side and which doesn't need special software to use would be cool, but why store the key in the browser cache (I'm assuming they mean "cookie"..)? You'd be way better off having them enter a password and generate a key based on that. Then it's not tied to a single computer, doesn't store secure keys in the cache and all you need is the password to jam.

How would you tie password to key without the provider having a copy there of (I guess if the key is generated from a password would work but I've no idea how to generate a valid two key set up from one)?

Yeah, just generate it from the password. That's actually how most systems that encrypt data using a user-supplied password work, because all of crypto algorithms require a fixed-length key. So say you need a 128-byte key for encryption, you sha1 the user-supplied password and then take the first 128 bytes and use that as your key.

Ok, which of the 20 bytes are we taking for our 128 byte key?

Some people take "pedantic dickweed" as a personal challenge..

morbiuswilters

@Lorne Kates said:

@Matches said:
we do have something in place that will destroy our hard disks in a matter of minutes

What sort of shitty "something" are they using that takes MINUTES to destroy a hard drive? Wow, the layers upon layers of fail are astounding.

Or maybe they're using Seagate drives and just hoping the MTBF will take care of things for them.

Planar

@morbiuswilters said:

Yeah, just generate it from the password. That's actually how most systems that encrypt data using a user-supplied password work, because all of crypto algorithms require a fixed-length key. So say you need a 128-byte key for encryption, you sha1 the user-supplied password and then take the first 128 bytes and use that as your key.

That's fine for symmetric crypto, but to make a good public/private key pair you need a lot of entropy. Your 128-byte example only provides 1024 bits, which is not considered secure these days. You'd need at least 2000 bits to be reasonably secure. Good luck getting that much entropy from a user-generated password: a typical English text provides about 1 or maybe 2 bits per character, so your users might be a bit upset when you tell them "Your password is not long enough to be secure. Please type at least 1000 characters."

And then there's the issue of generating the key from that entropy in a reasonable amount of time.

That's why people generate key pairs from system-supplied entropy, then store them encrypted (by a symmetric algorithm) with a user-supplied password.

morbiuswilters

@Planar said:

@morbiuswilters said:
Yeah, just generate it from the password. That's actually how most systems that encrypt data using a user-supplied password work, because all of crypto algorithms require a fixed-length key. So say you need a 128-byte key for encryption, you sha1 the user-supplied password and then take the first 128 bytes and use that as your key.

That's fine for symmetric crypto, but to make a good public/private key pair you need a lot of entropy. Your 128-byte example only provides 1024 bits, which is not considered secure these days. You'd need at least 2000 bits to be reasonably secure. Good luck getting that much entropy from a user-generated password: a typical English text provides about 1 or maybe 2 bits per character, so your users might be a bit upset when you tell them "Your password is not long enough to be secure. Please type at least 1000 characters."

And then there's the issue of generating the key from that entropy in a reasonable amount of time.

That's why people generate key pairs from system-supplied entropy, then store them encrypted (by a symmetric algorithm) with a user-supplied password.

Good point, I actually forgot we were talking about asymmetric keys.

That said, EC private keys are much shorter and can be generated from a passphrase, so that would be one way to get a key from a passphrase.

anotherusername

@morbiuswilters said:

@RaceProUK said:
@Matches said:
Lavaboom's JavaScript code and the user's private key is stored in the browser's cache
Works brilliantly for those who set their browser to clear the cache when it's closed down.

The really amazing thing is they're doing the crypto in JS. Have you ever tried that? Just doing an MD5 on a few dozen MB of data will cause the browser to explode. I can't even imagine how crap-tastic it is at doing real crypto.

Anyway, seems like having email that's encrypted client-side and which doesn't need special software to use would be cool, but why store the key in the browser cache (I'm assuming they mean "cookie"..)? You'd be way better off having them enter a password and generate a key based on that. Then it's not tied to a single computer, doesn't store secure keys in the cache and all you need is the password to jam.

That is what web workers are for! (You can design Javascript in such a way that it doesn't freeze the whole browser while it works, without using web workers... but it's rather painful)

It says you can download the key during registration, so I'd certainly hope it provides you with a base-64 or hex version that you can save someplace safe so that it's not totally hamstrung by a single cookie in your browser's cache.

dtech

@Planar said:

That's fine for symmetric crypto, but to make a good public/private key pair you need a lot of entropy. Your 128-byte example only provides 1024 bits, which is not considered secure these days. You'd need at least 2000 bits to be reasonably secure. Good luck getting that much entropy from a user-generated password: a typical English text provides about 1 or maybe 2 bits per character, so your users might be a bit upset when you tell them "Your password is not long enough to be secure. Please type at least 1000 characters."

And then there's the issue of generating the key from that entropy in a reasonable amount of time.

That's why people generate key pairs from system-supplied entropy, then store them encrypted (by a symmetric algorithm) with a user-supplied password.

Just use symetric crypto to encrypt the asymetric crypto private key

ratchet_freak

what I find impressive is that it ignores the transfer before the mail touches the lavaboom servers (where it won't be encrypted)

anotherusername

@ratchet freak said:

what I find impressive is that it ignores the transfer before the mail touches the lavaboom servers (where it won't be encrypted)

How do you figure, since everything is supposed to be encrypted and decrypted on the client side?

Lorne Kates

@anotherusername said:

It says you can download the key during registration, so I'd certainly hope it provides you with a base-64 or hex version that you can save someplace safe so that it's not totally hamstrung by a single cookie in your browser's cache.

Well, since this is SECURE webmail, you can just email the key to your Lavaboom email address. That way it's secure!

alegr

@Planar said:

That's fine for symmetric crypto, but to make a good public/private key pair you need a lot of entropy. Your 128-byte example only provides 1024 bits, which is not considered secure these days. You'd need at least 2000 bits to be reasonably secure.

I don't think you understand what it means.

Length of the RSA key (derived from a product of two primes) doesn't have to have anything common with your password length.

Entropy, by definition, is log() of number of possible states. If your key entropy is 64 bits then it's practically not worth to brute-force it. 128 bit - impossible to brute-force.

RSA key entropy is not equal its length. But that's a different problem.

vt_mruhlin

@morbiuswilters said:

why store the key in the browser cache (I'm assuming they mean "cookie"..)?

Cookies get sent to the server on every request...

Could very well be exactly how they implemented it though, since this is theDailyWTF...

HTML5 does support some local browser storage features that are distinctly different from cookies and caches, though. Actually designed for long-term storage, but still not bulletproof.

dkf

@vt_mruhlin said:

Cookies get sent to the server on every request...

Technically, they only get sent on matching requests, with separate rules about how hosts and paths are prefix-matched. And you can do some funky manipulations of cookies from JS too (though I think they're origin-restricted if you do that).

Disclosure: I've been looking at how this is all done recently, and “nasty botch” is probably the most generous thing I can say at this point.

morbiuswilters

@anotherusername said:

That is what web workers are for! (You can design Javascript in such a way that it doesn't freeze the whole browser while it works, without using web workers... but it's rather painful)

Definitely, my point was just doing crypto in JS is so slow that MD5 (a super-fast algo) on 20 megs of data will kill a browser. I just did an md5sum on a 63 MB file from the command line and it finished in less than a second. So it's slow.

It's also ludicrously insecure. Ignoring all of the possible browser vulnerabilities (browser plugins and extensions, XSS, bugs in browser implementations of web security features) it's also extremely vulnerable to side-channel attacks. Doing crypto well is incredibly hard. Some of the smartest programmers in the world work in crypto and they fuck it up all the time. It's silly to think doing it in a browser is going to work out well.

morbiuswilters

@dtech said:

@Planar said:
That's fine for symmetric crypto, but to make a good public/private key pair you need a lot of entropy. Your 128-byte example only provides 1024 bits, which is not considered secure these days. You'd need at least 2000 bits to be reasonably secure. Good luck getting that much entropy from a user-generated password: a typical English text provides about 1 or maybe 2 bits per character, so your users might be a bit upset when you tell them "Your password is not long enough to be secure. Please type at least 1000 characters."

And then there's the issue of generating the key from that entropy in a reasonable amount of time.

That's why people generate key pairs from system-supplied entropy, then store them encrypted (by a symmetric algorithm) with a user-supplied password.

Just use symetric crypto to encrypt the asymetric crypto private key

But then you have to store the encrypted private key somewhere--you can't just create it from a password each time you need it. (Unless you're using EC.) In fact, they might be doing what you say, and the encrypted private key is what they store in the cookie, which would be slightly more secure, although the whole service is still a bad idea.

morbiuswilters

@alegr said:

@Planar said:
That's fine for symmetric crypto, but to make a good public/private key pair you need a lot of entropy. Your 128-byte example only provides 1024 bits, which is not considered secure these days. You'd need at least 2000 bits to be reasonably secure.
I don't think you understand what it means.

Length of the RSA key (derived from a product of two primes) doesn't have to have anything common with your password length.

Entropy, by definition, is log() of number of possible states. If your key entropy is 64 bits then it's practically not worth to brute-force it. 128 bit - impossible to brute-force.

RSA key entropy is not equal its length. But that's a different problem.

Planar messed up the math, but he's still got a point: RSA keys require a decent amount of good entropy to not suck. In theory, you could take the password, hash it using something like SHA or bcrypt and then use that as a seed for a PRNG which would generate your entropy for your RSA key. However, to be really secure you'd still need a password with lots of entropy.

Now that does give you a deterministic way to go from password to private key, but it's also going to be slow as hell, because you are effectively re-generating the RSA key every time you want to decrypt something (or at least for every session within the system.) Generating RSA keys is slow enough from real apps, it would probably take an hour in Javascript, I'm not even joking.

Let me point out again how asinine this is. You're decrypting stuff in Javascript. Your private keys are just variables in JS. If a malicious party can inject some JS into the page, they can read anything they want. The whole point about the key never going to the server is completely irrelevant, because if someone has control of the server they can just get the key from your client without you knowing.

Ben L.

@morbiuswilters said:

Generating RSA keys is slow enough from real apps, it would probably take an hour in Javascript, I'm not even joking.

Really? That fast?

morbiuswilters

@vt_mruhlin said:

@morbiuswilters said:
why store the key in the browser cache (I'm assuming they mean "cookie"..)?

Cookies get sent to the server on every request...
Could very well be exactly how they implemented it though, since this is theDailyWTF...
HTML5 does support some local browser storage features that are distinctly different from cookies and caches, though. Actually designed for long-term storage, but still not bulletproof.

Using HTML5 local storage would make no difference. If the server wants the key, it can get the key just by injecting some JS to read the key. How would the user know?

But "browser cache" makes even less sense. How would the client go about creating a cache entry for the key? I don't even understand what they mean by that..

oheso

@morbiuswilters said:

Midget with a ball-peen hammer locked in the server cabinet?

Fuck, morbs, did you have to publish our secret? Now we'll have to think of a different way.

oheso

@morbiuswilters said:

you sha1 the user-supplied UPPERCASE password and then take the first 128 bytes and use that as your key.

FTFY

morbiuswilters

@oheso said:

@morbiuswilters said:
you sha1 the user-supplied UPPERCASE password and then take the first 128 bytes and use that as your key.

FTFY

Passwords must obey the following policy:

Be between 5 and 7 characters
BE UPPERCASE ONLY
Contain at least one digit
Contain precisely zero non-alphanumeric characters
The number of digits in the password must be a prime number
The password cannot be entirely digits, unless it is also a prime number
An exception to the above rule is "8675309" which, although prime, is also from that Tommy Tutone song, and thus not allowed
The following UPPERCASE letters are forbidden as they remind me of naughty bits: A, B, C, D, I, L, M, N, O, P, Q, S, T, U, V, W, X, Y
The system will let you choose a password that does not meet these criteria, but then you will never be able to login. In that case, you can seek help from our support desk, but they have been instructed to handle these cases by going through your email until they find compromising photos of you and then leak them to friends and family.
If they are unsuccessful at finding compromising photos of you, some will be fabricated by our crack Photoshopists using un-compromising photos of you and public domain Miley Cyrus crotch shots and nip slips.

Ben L.

@morbiuswilters said:

If they are unsuccessful at finding compromising photos of you, some will be fabricated by our crack Photoshopists using un-compromising photos of you and public domain Miley Cyrus crotch shots and nip slips.

Even if I'm male?

@Ben L. said:

@morbiuswilters said:
If they are unsuccessful at finding compromising photos of you, some will be fabricated by our crack Photoshopists using un-compromising photos of you and public domain Miley Cyrus crotch shots and nip slips.

Even if I'm male?

Especially if you're male.

morbiuswilters

@Ben L. said:

@morbiuswilters said:
If they are unsuccessful at finding compromising photos of you, some will be fabricated by our crack Photoshopists using un-compromising photos of you and public domain Miley Cyrus crotch shots and nip slips.

Even if I'm male?

If?

drurowin

@morbiuswilters said:

If?

(I had typed a small-penis joke here, but decided it was in bad taste. Instead, have a remark about how the USA's default religion is the wrong one.)
So, what percentage of America is going to be closed for the next five days because a Jew supposedly killed ~~your Lord and Saviour Jesus M. Christ~~ some Hebrew carpenter roughly 1,980 years ago? (Good Friday, Better Saturday, Easter Sunday, Post-Easter Monday, and Easter Hangover Tuesday, for those who insist I show my working...)