Online Security at it's best

[+Warwagon MVC]

So I recently signed up for the dating website Plentyoffish.com, ya I know but for them most part all of it is free, so that's cool.

Well once a week (I probably should unsubscribe) they send me an email saying New matches for October 10. That's not so bad. What is included in the email is disturbing.

Below is a copy of the email.

First they say Hello ____________, telling my username which isn't so bad most sites do. But then it goes on to say

Thank you for signing up for Plentyoffish.com

Remember your password is ____________.

It then proceeds to give out your password for plentyoffish.com.

I know this email should be private being it's getting sent to the persons email, but what if someone logs into your email account. Long story short websites should not be including the ****ing password in an email PERIOD!.

[JoeyF]

I know this email should be private being it's getting sent to the persons email, but what if someone logs into your email account.

Um........ I think they'd already know your password if that was the situation......

And don't forget, there's always the "forgot password" button, which would give them your pass anyway if they got into your email.....

[+Warwagon MVC]

Um........ I think they'd already know your password if that was the situation......

And don't forget, there's always the "forgot password" button, which would give them your pass anyway if they got into your email.....

You are correct, but what if someone just access my email when I have it open on my computer.

[Kondrath]

I remember myspace used to do this back in the day... So dumb.

[WelshBluebird]

Many different websites do this really. Not that its good, but there you go.

[+LogicalApex MVC]

The problem isn't someone hacking into your email and finding out the password by looking in the box...

When sent via regular, non-encrypted email, it can easily be sniffed out on the wire at ANY point between the original server and the destination box. It can also be stored in log files on any of those servers along the way...

Meaning the hacking could be done without the user EVER being directly touched and knowing!

[+Warwagon MVC]

The problem isn't someone hacking into your email and finding out the password by looking in the box...

When sent via regular, non-encrypted email, it can easily be sniffed out on the wire at ANY point between the original server and the destination box. It can also be stored in log files on any of those servers along the way...

Meaning the hacking could be done without the user EVER being directly touched and knowing!

You would think after the Sony tabockle, companies would be more careful with people's data. Lesson learned? Apparently not.

[Miuku.]

When sent via regular, non-encrypted email, it can easily be sniffed out on the wire at ANY point between the original server and the destination box. It can also be stored in log files on any of those servers along the way...

True but then it would have to be someone from the ISP or backbone.

The only way someone could sniff it would be if you accessed your mail from say an IMAP server with no TLS/SSL in an untrusted LAN (University/College network or public unencrypted WLAN in which case you deserve to be haxed :p)

[+Warwagon MVC]

True but then it would have to be someone from the ISP or backbone.

The only way someone could sniff it would be if you accessed your mail from say an IMAP server with no TLS/SSL in an untrusted LAN (University/College network or public unencrypted WLAN in which case you deserve to be haxed :p)

Still the principle of the thing. Plus they are apparently storing passwords and not hashes.

[+LogicalApex MVC]

True but then it would have to be someone from the ISP or backbone.

The only way someone could sniff it would be if you accessed your mail from say an IMAP server with no TLS/SSL in an untrusted LAN (University/College network or public unencrypted WLAN in which case you deserve to be haxed :p)

You have no idea of the network topology between the origin and the destination. A sniffer at ANY point on that path could wreak for you by sniffing out the data.

For instance, there could a sniffer sharing a LAN segment with the application's mailbox server (MTA) on the same hosting subnet that sniffs it out very close to the point of origin...

Or

When the mail is being received by your MTA the link between the perimeter MTA and the next hop from the origin MTA could be sniffed out...

Packet sniffing isn't as hard as you think it is...

The only way to be safe is to treat email as being 100% open and as such sensitive information should never be transmitted via it. The only time you can reasonably trust the security of the message is when it is either sent in an encrypted form or when it is sent via two users on the same domain AND you have 100% control over the MTA and can ensure that information on it is secure and safe... The latter is not possible with ANY email transmitted online, especially transactional mail such as has been posted here by Warwagon.

[HawkMan]

Obviously they arent hashing passwords.

Most likely they are, or rather they are encrypting it at both ends.

[+LogicalApex MVC]

Most likely they are, or rather they are encrypting it at both ends.

Not possible...

1. HASH is ONE WAY (i.e. not reversible)

2. Sending it in plain text voids ANY security you had on it if you did use something like SSL level reversible encryption.

[+Warwagon MVC]

Not possible...

1. HASH is ONE WAY (i.e. not reversible)

2. Sending it in plain text voids ANY security you had on it if you did use something like SSL level reversible encryption.

Exactly. Plus they wouldn't store the password, just the hash, which is why sites that hash have no password character limit. The fact they can provide me with my original password makes it obvious no hashing is taking place. If they were hashing they wouldn't have my password.

At least that's what I've gathered from the security now podcast.

[dragon2611]

- Accidently entered an old password into facebook and was more than a little suprised to see this error message.

Yes that's really great isn't it?

Also if you try to login with someones email address enough times facebook will eventually disclose who that user is, not everyone has their name in their email address so facebook are essentialy then linking a internet alias with a real person.

[+Xinok Subscriber²]

Accidently entered an old password into facebook and was more than a little suprised to see this error message.

Yes that's really great isn't it?

Also if you try to login with someones email address enough times facebook will eventually disclose who that user is, not everyone has their name in their email address so facebook are essentialy then linking a internet alias with a real person.

I don't even give Facebook my real email address. I created a random email address just for them, for this exact reason.

[HawkMan]

Not possible...

1. HASH is ONE WAY (i.e. not reversible)

2. Sending it in plain text voids ANY security you had on it if you did use something like SSL level reversible encryption.

Hence why I said they didn't hash i, but just plain encrypted it, a lot of sites and services do this. they encrypt it during transmission, and encrypt it in their database, that way they can decrypt it and send it to the user on request, instead of all those ass backwards annoying, secret question and all the other idiotic password reset functions.

though this method is at least as secure as Hash, sending the password in the mail without the user requesting it is rather stupid of them.

[+LogicalApex MVC]

Hence why I said they didn't hash i, but just plain encrypted it, a lot of sites and services do this. they encrypt it during transmission, and encrypt it in their database, that way they can decrypt it and send it to the user on request, instead of all those ass backwards annoying, secret question and all the other idiotic password reset functions.

though this method is at least as secure as Hash, sending the password in the mail without the user requesting it is rather stupid of them.

I would disagree. Encrypting it in transmission only makes you secure against having the password sniffed out on the wire. It doesn't protect you against having you database server hacked into and the unencrypted data being stolen or your application server being hacked and the decryption keys being siphoned off to make wire sniffing possible again.

I would wager that protecting against the data itself being stolen is far more important (in a website login scenario) than protecting against wire snooping (between the application and its back-end data store, communication between the site and end user should always be HTTPS for login)

[HawkMan]

I would disagree. Encrypting it in transmission only makes you secure against having the password sniffed out on the wire. It doesn't protect you against having you database server hacked into and the unencrypted data being stolen or your application server being hacked and the decryption keys being siphoned off to make wire sniffing possible again.

I would wager that protecting against the data itself being stolen is far more important (in a website login scenario) than protecting against wire snooping (between the application and its back-end data store, communication between the site and end user should always be HTTPS for login)

Hence why I said it was kept encrypted in their database, this is what most sites who don't run simple public scripts today operate, an encrypted DB, with password stored, and passwords encrypted in transfer, unless you request it in mail, naturally. Being stored in a databse so the password can be read/recovered does not naturally means it's stored in plaintext.