4 ms·

The thing that really blows my mind about this whole story is this: What the fuck was a bank doing sending the confidential information of thousands to a GMail

The thing that really blows my mind about this whole story is this: What the fuck was a bank doing sending the confidential information of thousands to a GMail account in the first place?

stakent 17y ago
And why all emails were not strongly encrypted?
- seiji 17y ago
  Have you ever seen an encrypted email sent to a wide audience?
  - NathanKP 17y ago
    Hopefully they weren't sending social security numbers and account info to a wide audience.
  - stakent 17y ago
    Did I say its easy? The point is that there is an organisation. And some people are responsible for security. And yes, it will cost.
    - jrockway 17y ago
      Why do it right when the legal system is perfectly happy to violate the rights of innocent people at no cost to you? "It's the economy, stupid."
- blasdel 17y ago
  Fuck encrypting the email itself -- it should only contain a link to an https site that the intended recipient has credentials to log into (preferably with multi-factor auth). This is what real, grownup banks do!
- Dobbs 17y ago
  My understanding is they were breaking regulation by not. The company I work for does customer opinion surveys. We occasionally do some for a large national bank. When we send data, of any form to the bank we are required to encrypt the email before we send it. This is just for something like random customer surveys not even at the level of actual account data.
jwecker 17y ago
"Hi, you received an email from us yesterday with confidential information. Please contact us immediately and destroy the file. It's the email with the subject 'Re: Do we have a way to back up our data?'"
lnguyen 17y ago
There's absolutely no reason for it to have been done. That type of information should only be available to pre-approved, secured email addresses. And that certainly should be a company.com address, not gmail.com. The only plausible "excuse" would be that an employee decided to take a shortcut thinking that no harm would be done (and no one would know) and had a "oh f*ck!" realization when it went to the wrong address (and don't they wish they were using GMail with Undo!). This is still unacceptable. If it was a common and accepted practice, it's inexcusable.
NathanKP 17y ago
What the fuck was a bank doing sending the confidential information of thousands to a GMail account in the first place? Maybe the employees were so irritated with Microsoft outlook they have been using Gmail instead. But seriously if I were a member of that bank I would be withdrawing my money right away. If there security procedures are so lax that they send a confidential email such as that through Gmail then they aren't responsible enough to hold anyone's money.
jhancock 17y ago
Don't count on a bank handling data security well. Here's a story for ya', I won't use the bank's real name, but it rhymes with HSBC. Anyway, a while back, I was logging into my online banking and the password no longer worked. So I called tech support to see what's up. They said, oh yeah, your password can't be more than 8 characters now. If it was more than that previously, it got truncated [not sure they actually used that word], so try the first 8 characters. So what does this tell you about the way they were/are storing my password?
- frisco 17y ago
  (Hint: you can't truncate a hash and get a subset string of the original password to still work.)
  - jhancock 17y ago
    +1 for frisco (hopefully most of us) that understands the basics of a one-way hash!! The more precise answer is they at least were storing password in plaintext.
    - jedediah 17y ago
      It could be that the bank was hashing the passwords all along, but just truncating the user's input before hashing it and comparing it to the saved value. Not that I think this is what happened, but I'm just saying it could be.
      - deleted 17y ago
        [deleted]
      - RobKohr 17y ago
        Then would would the newly entered shorter value match to? 123456 -> hash code 1 123 -> hash code 2 (which doesn't exist in their db)
        deleted 17y ago

The thing that really blows my mind about this whole story is this: What the fuck was a bank doing sending the confidential information of thousands to a GMail account in the first place?

stakent 17y ago

And why all emails were not strongly encrypted?

seiji 17y ago
Have you ever seen an encrypted email sent to a wide audience?
- NathanKP 17y ago
  Hopefully they weren't sending social security numbers and account info to a wide audience.
- stakent 17y ago
  Did I say its easy? The point is that there is an organisation. And some people are responsible for security. And yes, it will cost.
  - jrockway 17y ago
    Why do it right when the legal system is perfectly happy to violate the rights of innocent people at no cost to you? "It's the economy, stupid."
blasdel 17y ago
Fuck encrypting the email itself -- it should only contain a link to an https site that the intended recipient has credentials to log into (preferably with multi-factor auth). This is what real, grownup banks do!
Dobbs 17y ago
My understanding is they were breaking regulation by not. The company I work for does customer opinion surveys. We occasionally do some for a large national bank. When we send data, of any form to the bank we are required to encrypt the email before we send it. This is just for something like random customer surveys not even at the level of actual account data.

jwecker 17y ago

"Hi, you received an email from us yesterday with confidential information. Please contact us immediately and destroy the file. It's the email with the subject 'Re: Do we have a way to back up our data?'"

lnguyen 17y ago

There's absolutely no reason for it to have been done. That type of information should only be available to pre-approved, secured email addresses. And that certainly should be a company.com address, not gmail.com. The only plausible "excuse" would be that an employee decided to take a shortcut thinking that no harm would be done (and no one would know) and had a "oh f*ck!" realization when it went to the wrong address (and don't they wish they were using GMail with Undo!). This is still unacceptable. If it was a common and accepted practice, it's inexcusable.

NathanKP 17y ago

What the fuck was a bank doing sending the confidential information of thousands to a GMail account in the first place? Maybe the employees were so irritated with Microsoft outlook they have been using Gmail instead. But seriously if I were a member of that bank I would be withdrawing my money right away. If there security procedures are so lax that they send a confidential email such as that through Gmail then they aren't responsible enough to hold anyone's money.

jhancock 17y ago

Don't count on a bank handling data security well. Here's a story for ya', I won't use the bank's real name, but it rhymes with HSBC. Anyway, a while back, I was logging into my online banking and the password no longer worked. So I called tech support to see what's up. They said, oh yeah, your password can't be more than 8 characters now. If it was more than that previously, it got truncated [not sure they actually used that word], so try the first 8 characters. So what does this tell you about the way they were/are storing my password?

frisco 17y ago
(Hint: you can't truncate a hash and get a subset string of the original password to still work.)
- jhancock 17y ago
  +1 for frisco (hopefully most of us) that understands the basics of a one-way hash!! The more precise answer is they at least were storing password in plaintext.
  - jedediah 17y ago
    It could be that the bank was hashing the passwords all along, but just truncating the user's input before hashing it and comparing it to the saved value. Not that I think this is what happened, but I'm just saying it could be.
    - deleted 17y ago
      [deleted]
    - RobKohr 17y ago
      Then would would the newly entered shorter value match to? 123456 -> hash code 1 123 -> hash code 2 (which doesn't exist in their db)
      - deleted 17y ago