Elliott C. Back: Internet & Technology

How to Protect Your Password

Posted in Cracking, Hacking, Security, Spam by Elliott Back on June 7th, 2012.

You may have read about the tens of millions of usernames and passwords which have been recently been compromised/hacked/leaked on major websites in the last few weeks. If not, here are a few of the stories:

  • 30 million passwords leaked from LinkedIn due to unsalted SHA-1 hashes stored centrally.
  • 6 million passwords hacked at Last.FM, the popular music discovery service.
  • 1.5 million passwords leaked from eHarmony.

In the last year other services have experience serious security breaches:

  • 100 million accounts compromised on the Sony Playstation Network (PSN). Sony offered free credit monitoring and games to all PSN users to compensate them, a major departure from the typical “change your password” / sweep it under the rug response.
  • All RSA SecureID tokens were compromised by the theft of RSA intellectual property and cryptographic keys. RSA tokens are used by most enterprises to login remotely as part of multi-factor authentication scheme.

How can you protect yourself?

Signup for a service like 1Password or LastPass, which offer convenient browser extensions. They generate unique passwords per website that you user, so the breach of security at Facebook won’t affect your password on Mint.

How can Web Developers protect users?

Move to standardized authentication methods, like OpenID or Facebook/Twitter/Google login integration. If the authentication mechanism is outsourced, your customers and users don’t need to worry about how you store their passwords.

If you absolutely want to store user passwords, please read How to Safely Store a Password and use bcrypt to do the heavy lifting. Then even if your login/password database is compromised, nothing will come of it.

Dealbreaker Sucks

Posted in Blogging, Finance, Spam by Elliott Back on March 3rd, 2012.

I think it’s time to stop reading dealbreaker in my google reader feeds:

Let’s see why:

  • Two “continue reading” links
  • No full text RSS feed
  • An ugly and stupid “follow Dealbreaker” banner that I doubt anyone will ever click
  • A gigantic google-style text link ad

We wish the web would allow information to transmit openly, but sites continue to push monetization over content. It’s time to switch!

GMail Blocking Chase Emails as Spam

Posted in Google, Spam by Elliott Back on September 23rd, 2011.

For whatever reason, Gmail keeps blocking my account alert emails from Chase. In my spam folder, guess which are really spam, and which are legit?

When I move them to my inbox and/or mark them as spam, I get warned that “Warning: This message may not be from whom it claims to be. Beware of following any links in it or of providing the sender with any personal information.”

How do I get Google to believe that my emails from Chase are real? I keep marking them as not spam, but that doesn’t help! Ridiculous that Gmail is hurting Chase Bank’s ability to conduct business and manage their fraud/risk. I highly suspect that account fraud alerts would get thrown into the same bucket…

Update 1:

The message headers seem to indicate a failure between Cornell and Google’s servers on SPF (Sender Policy Framework):

Delivered-To: XXXX@gmail.com
Received: by 10.231.53.18 with SMTP id k18cs6777ibg;
Sat, 24 Sep 2011 05:13:22 -0700 (PDT)
Received: by 10.52.93.112 with SMTP id ct16mr4101007vdb.423.1316866401115;
Sat, 24 Sep 2011 05:13:21 -0700 (PDT)
Return-Path: <Chase@alerts.chase.com>
Received: from limestone3.mail.cornell.edu (limestone3.mail.cornell.edu. [128.253.83.163])
by mx.google.com with ESMTP id bz6si11946296vdc.126.2011.09.24.05.13.20;
Sat, 24 Sep 2011 05:13:21 -0700 (PDT)
Received-SPF: fail (google.com: domain of Chase@alerts.chase.com does not designate 128.253.83.163 as permitted sender) client-ip=128.253.83.163;
Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of Chase@alerts.chase.com does not designate 128.253.83.163 as permitted sender) smtp.mail=Chase@alerts.chase.com; dkim=hardfail header.i=@alerts.Chase.com

X-CornellRouted: This message has been Routed already.

Update 2: A helpful Googler/blog reader said this:

It appears to be a problem specifically with Cornell. It’s a known issue when Cornell is forwarding e-mails to GMail. The Cornell IT admins [are fixing] their exchange server. In the meantime you can fix this with either:

- have Chase send info direct to @gmail.com
- create a filter to “never mark as spam” for that address.

My solution is to change my old rules to email directly to gmail rather than forward through Cornell’s servers.

Next Page »