Ideal ZFS Configurations | TechSNAP 135

Ideal ZFS Configurations | TechSNAP 135

Striking a balance between performance and reliability can be a challenge, we’ll share our thoughts. Hackers figure out how to take over twitter account they want, while Adobe stores your private data in reversible encryption.

Plus your questions, our answers, and much much more.

Thanks to:



Direct Download:

HD Video | Mobile Video | MP3 Audio | Ogg Audio | YouTube | HD Torrent | Mobile Torrent

RSS Feeds:

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feeds | Torrent Feed

Adobe encrypted passwords, rather than cryptographically hashing them

  • This is a detail reporters often get wrong, saying that passwords were ‘encrypted’ when they meant ‘hashed’
  • Turns out, Adobe actually did it WRONG
  • The Adobe breach gave the attackers access to a 9.3 GB database containing 130 million user accounts and their passwords
  • The problem is that the passwords are stored using ‘reversible’ encryption (standard symmetric encryption, normally used on files), rather than cryptographic hashes (one-way encryption)
  • This means that if the attacker manages to get or brute force the private key that was used to encrypt the passwords, they would be able to decrypt EVERY password, in one go
  • Many of the accounts in the Adobe database belong to government organizations including the FBI, as well as many large corporations
  • The passwords were encrypted using 3DES (Triple DES)
  • DES was originally introduced in 1977, and 3DES in 1998 because the 56 bit keys in DES were no longer strong enough
  • Adobe also used ECB (Electronic Code Book) mode, which is known to leak information about the passwords
  • 3DES was superseded in 2001 by AES
  • Unliking with a cryptographic hashing algorithm, where the server does not know each users’ password, upgrading from 3DES to AES would have been easy, just decrypt all passwords and encrypt them with the new algorithm
  • Or better yet, decrypt all passwords, and properly cryptographically hash them and then throw away the plain text
  • “For more than a year, Adobe’s authentication system has cryptographically hashed customer passwords using the SHA-256 algorithm, including salting the passwords and iterating the hash more than 1,000 times. This system was not the subject of the attack we publicly disclosed on October 3, 2013. The authentication system involved in the attack was a backup system and was designated to be decommissioned. The system involved in the attack used Triple DES encryption to protect all password information stored.”

Hackers Take Limo Service Firm for a Ride

  • A break in at a U.S. company that brokers reservations for limousine and Town Car services nationwide has exposed the personal and financial information on more than 850,000 customers, including Fortune 500 CEOs, lawmakers, and A-list celebrities.
  • The high-value data cache was found on the same servers where hackers stashed information stolen from PR Newswire, as well as huge troves of source code data lifted from Adobe Systems Inc.
  • Suggesting that the same attacker(s) may have been involved in all three compromises.
  • The name on the file archive reads “CorporateCarOnline.”
  • That name matches a company based in Kirkwood, Missouri which bills itself as “the leading provider of on-demand software management solutions for the limousine and ground transportation industry.”
  • Inside the plain text archive apparently stolen from the firm are more than 850,000 credit card numbers, expiry dates and associated names and addresses.
  • More than one-quarter (241,000) of all compromised card numbers were high- or no-limit American Express accounts.
  • Further pointing to a compromise at the site is the presence of a vulnerability in its implementation of ColdFusion.

Researcher finds way to take over ANY twitter account

  • Security researcher Henry Hoggard discovered a cross-site request forgery (CSRF) vulnerability in Twitter’s “add a mobile device” feature
  • Using this, he was able to read any user’s tweets and DMs
  • A victim that went to a malicious page, would unexpectedly authorize a new device to access their twitter account
  • This should have been prevented by Twitter’s verification step, except it seems that twitter was not actually checking the value, so an attacker would authorize their mobile device on your account by entering any value in place of the verification code
  • Twitter fixed the issue within 24 hours of it being reported


Round Up:

Question? Comments? Contact us here!