Are Passwords Immortal? – Security Now 690

Pwn2Own, the Future of Passwords.
— All the action at last week’s Pwn2Own Mobile hacking contest
— The final word on processor mis-design in the Meltdown/Spectre era
— A workable solution for unsupported Intel firmware upgrades for hostile environments
— A forthcoming Firefox breach alert feature
— The expected takeover of exposed Docker-offering servershe recently announced successor to recently ratified HTTP/2
— 1.1.1.1 errata
— The future of passwords: a thoughtful article written by Troy Hunt, the creator of the popular “Have I Been Pwned” web service We invite you to read our show notes.

Hosts: Steve Gibson, Leo Laporte

Security Now 657: ProtonMail

This week we discuss “DrupalGeddon2”, Cloudflare’s new DNS offering, a reminder about GRC’s DNS Benchmark, Microsoft’s Meltdown meltdown, the persistent iOS QR Code flaw and its long-awaited v11.3 update, another VPN user IP leak, more bug bounty news, an ill-fated-seeming new eMail initiative, Free electricity, a policy change at Google’s Chrome store, another “please change your passwords” after another website breach, a bit of miscellany, a heart-warming SpinRite report, some closing the loop feedback from our terrific listeners, and a closer look at the Swiss encrypted ProtonMail service.

Security question answers are less secure than the passwords they help protect

We’re reminded on a regular basis that password security is of the utmost importance. Concepts like selecting strong passwords, using unique passwords for each login and not sharing your passwords are general knowledge at this point although many choose to ignore the advice.

Unsurprisingly, we’re also just as bad when it comes to providing answers to security questions when signing up for a new site or service but it’s not always the user’s fault.

Security questions are designed to provide an extra layer of security or to help recover a password that you no longer remember. But as data from a recent study conducted by Google’s security team reveals, they generally offer even less security than the passwords themselves.

google study shows security questions secure passwords credentials login credentials security questions usernames

People often choose answers that are easy to remember which by nature, aren’t very secure because the answers often contain commonly known or publicly available information. Examples of popular security questions include asking the name of your first pet, your favorite food or your mother’s maiden name.

Conversely, difficult answers are often too tough to remember and thus, defeat the entire purpose of a security question. The team found that 40 percent of English-speaking users in the US couldn’t recall their secret question answers when needed.

Some of the safest questions, like asking for a user’s library card number or their frequent flyer number, only had a recall rate of 22 percent and nine percent, respectively.

The team’s findings, summarized in a paper recently presented at WWW 2015, led them to conclude that secret questions are neither secure nor reliable enough to be used as a standalone account recovery mechanism.

via Security question answers are less secure than the passwords they help protect – TechSpot.

Mozilla warns of leaky developer network database

Mozilla’s website for developers leaked email addresses and encrypted passwords of registered users for about a month due to a database error, the organization said Friday.

Email addresses for 76,000 Mozilla Development Network (MDN) users were exposed, along with around 4,000 encrypted passwords, wrote Stormy Peters, director of development relations, and Joe Stevensen, operations security manager in a blog post. Mozilla is notifying those affected.

No malicious activity on the affected server was detected, but that does not mean the data wasn’t accessed, they wrote.

A Web developer discovered around 10 days ago that a data sanitization process on the database running the MDN wasn’t working. The leak started around June 23 and continued for a month.

“As soon as we learned of it, the database dump file was removed from the server immediately, and the process that generates the dump was disabled to prevent further disclosure,” they wrote.

The exposed passwords were encrypted and “salted,” a security measure that makes it difficult to revert them to their original form. Even if the passwords were decrypted, “they by themselves cannot be used to authenticate with the MDN website today,” according to the post.

Since some people may used the same MDN password on other websites, it’s recommended the password be changed.

Mozilla said it was “deeply sorry” for the error.

“In addition to notifying users and recommending short term fixes, we’re also taking a look at the processes and principles that are in place that may be made better to reduce the likelihood of something like this happening again,” according to the post.

via Mozilla warns of leaky developer network database | PCWorld.

How Google declared open war against passwords at I/O

Google hasn’t been shy in the past about its desire to kill the password, and at Google I/O, the company started throwing punches.

The next version of Android will include several ways to unlock a smartphone without having to enter a PIN or lockscreen pattern, a feature dubbed “personal unlocking.” If the user is wearing an Android Wear smartwatch, the phone will unlock automatically, and you’ll be able to set up trusted locations, such as home or work, where a PIN isn’t required, or use a voiceprint to unlock the phone. The capabilities carry over to Chrome OS; Chromebook users will be able to automatically authenticate themselves via a paired Android phone, unlocking the laptop and logging into your Google account without ever having to bother with a single password.

Chromecast, meanwhile, is getting its own password-skipping trick: When you have guests over, they’ll be able to cast videos to the television without being on your Wi-Fi network. Google said it sends an ultrasonic code to the phone to figure out when the user is in the same room as the Chromecast, and it’ll fall back on a PIN when it can’t pinpoint the user’s location.

None of these approaches are going to obviate the password outright. They’re merely supplements, aimed at keeping you from entering the same string of letters and numbers over and over. The idea is if you can unlock your phone with little effort, you might actually take the extra step of adding a PIN in the first place—a hugely beneficial security practice.

Still, it’s easy to see how the added layer of security could spread to other apps and services. Apple is already moving in this direction with TouchID, the fingerprint sensor that’s built into the iPhone 5S. Currently, TouchID can only unlock the iPhone and authorize iTunes purchases, but in iOS 8, Apple is opening up the sensor to third-party apps. This will allow users to add an extra layer of security to sensitive apps without requiring a password every time

In the future, Google could offer similar security features in Android apps through Bluetooth pairing or location-based authentication. A paired smartwatch or smartphone could also potentially serve as the second step in two-factor authentication, providing extra security when logging into a new device without the hassle of verification codes—in fact, some enterprise notebooks already support Bluetooth phone pairing as a secondary authentication method. With this added security layer in place for your Google account, Google+ sign-in could even act as a master key for other apps and services. At that point, remembering dozens of passwords starts to become obsolete.

The new sign-in methods Google announced at I/O are just a first step—one that’s less extreme than the tattoos and authentication pills that researchers have been dreaming up. But if users end up embracing wearable technology, it could be the start of a full-blown assault on passwords and PINs.

via How Google declared open war against passwords at I/O | PCWorld.

It’s official: Malicious hackers have crappy password hygiene, too

Given the amount of time malicious hackers spend bypassing other people’s security, you might think that they pay close attention to locking down their own digital fortresses. It turns out that many of them don’t, according to a recent blog post documenting some of their sloppiest password hygiene.

The post comes from Antonín Hýža, a researcher at antivirus provider Avast. As he was working to analyze a protected PHP shell, he got to wondering how strong the average hacker password was. He then tapped 40,000 samples of backdoors, bots, and shells his company had on hand. Remarkably, 1,255 of the underlying passwords were in plaintext, while another 346 were protected with the easily crackable MD5 hashing algorithm. The resulting 1,601 passwords he had to work with allowed him to see just how poor the bottom four percent of hackers’ passwords were.

The fact that slightly more than three percent of the sample was in the clear was the first sign of just how sloppy some of the criminals Avast tracks are when it comes to password hygiene. These passwords can likely be obtained simply by viewing the scripts of programming languages, or in the case of binary code, by loading them into a hex viewer. As a result, a password with 75 characters, as one hacker set, or the passcode “lol dont try cracking 12 char+” (minus the quotes) chosen by another were easily recovered despite the work that went into trying to make them strong. The lack of any one-way hashing algorithm to obscure the passcodes makes one wonder why the authors bothered at all.

This table shows that the average password length was just six characters. Only 52 passwords had a length exceeding 12 characters.

Then there were the passwords themselves. The average length was just six characters, short enough to be brute-force cracked in a matter of minutes in most cases. The passwords also contained a relatively small number of upper-case letters, numbers, and special characters. By sticking mostly to predictable lower-case letters, the hackers significantly reduced the “key space” required to carry out brute-force attacks. That plays to the favor of crackers, since small key spaces take much less time to exhaust. By using a more diverse set of characters to create passwords, key spaces become orders of magnitude larger, a dynamic that can quickly make brute-force cracking unfeasible. Based on a statistical analysis of the recovered passwords, Hýža constructed two character sets that stood the best chance of quickly cracking the remaining undeciphered passcodes. The shorter of the two contained just 28 characters: acdehiklmnorstu01234579!-.@_

Besides a lack of character diversity, password choices were marred by the same cast of horrible words found in just about every cracked database.

“There [were] a lot of variations of the word pass and root and also hax was used many times, but if I omit one common 4-letter word, the most frequently used word in this dictionary is hack,” Hýža wrote. “It is worth mentioning that many PHP shells I analysed had only default passwords like r57, c99, password or yourpass.”

Further Reading

How the Bible and YouTube are fueling the next frontier of password cracking

Crackers tap new sources to uncover “givemelibertyorgivemedeath” and other phrases.

Ars has spent more than two years chronicling the password follies of end users and Web services alike. While the methodology in Hýža’s analysis focused only on the lowliest dregs of criminals’ passwords, it’s vaguely comforting to know that this group, too, struggles to pick strong passcodes.

via It’s official: Malicious hackers have crappy password hygiene, too | Ars Technica.

AOL Mail hit by cyber attack; asks users to change passwords

AOL’s free email service may not be as popular nowadays compared to Outlook.com, Gmail or even Yahoo Mail. However, the service still has over 20 million accounts and on Monday, AOL said that it got hit with a cyber attack.

In a press release, the company said it started an internal investigation following reports of an increase of spam email that were spoofed from AOL Mail addresses. It added:

AOL’s investigation is still underway, however, we have determined that there was unauthorized access to information regarding a significant number of user accounts. This information included AOL users’ email addresses, postal addresses, address book contact information, encrypted passwords and encrypted answers to security questions that we ask when a user resets his or her password, as well as certain employee information.

The unknown cyber criminal group is believed to have used this information to generate the spoofed email messages from about 2 percent of AOL’s email accounts; the company is now urging all of its email users to change their passwords.

The good news? AOL claims there is no evidence that any encryption methods on the passwords or security questions have been broken. There’s also no indication that any financial information such as credit card numbers were taken during the attack.

via AOL Mail hit by cyber attack; asks users to change passwords – Neowin.

Can this $70 dongle stem the epidemic of password breaches?

Security researchers have developed a password storage system that uses inexpensive hardware to prevent the cracking of passwords—even the most common and weak ones such as “123456,” “password,” and “letmein.”

The S-CRIB Scrambler uses an additional layer of protection over methods many websites use now to prevent mass account compromises in the event a password database is exposed during a site breach, according to a post published Friday on the University of Cambridge’s Light Blue Touchpaper blog. Rather than relying solely on a one-way cryptographic hash to represent plaintext passwords, the small dongle performs an additional operation known as hash-based message authentication code (HMAC). The secret 10-character key used to generate the HMAC resides solely on the dongle. Because it’s not included in password tables that are stored on servers, the key could remain secret even in the event of a major security breach.

Further Reading

Why passwords have never been weaker—and crackers have never been stronger

Thanks to real-world data, the keys to your digital kingdom are under assault.

The new method comes amid twin epidemics of website security breaches that spill password databases and a large percent of end users who use “princess,” “123abc,” and other easily guessed passcodes to safeguard their accounts. Like a similar approach unveiled last year that uses a hardware security module to encrypt hashed passwords, it’s designed to make it much harder for attackers to guess the plaintext corresponding to the hashes in a leaked database. Even if a hacker gains access to hashes protecting “123456” or other extremely weak passwords, there is no way to crack them.

“The trick is if you just get the hash from the database you can’t crack it because you don’t have the secret key that was used to create the HMAC hash, because that secret key is only in that hardware dongle,” Jeremi Gosney, a password security expert at Stricture Group who reviewed the Light Blue Touchpaper post, explained. “It’s using a secret parameter to hash the password inside that hardware dongle. You wouldn’t just be able to take the hash from the database and crack as a regular SHA1. It will look like a SHA1 hash, and you can try to crack it as a SHA1, but without knowing that key and cracking it as an HMAC SHA1 hash, you would never crack it.”

Got scale?

The $70 S-CRIB Scrambler plugs into a Raspberry Pi device, making it an inexpensive way to bolster the password storage of smaller sites. While the approach is receiving a fair amount of attention from security experts, many have raised doubts that the dongle has the horsepower or throughput larger websites require to authenticate users who number in the tens or hundreds of millions. A single dongle can scramble about 330 passwords per minute remotely over a connection with end-to-end encryption. That’s enough capacity to serve about 10,000 users. Websites can boost the amount of throughput by creating clusters of dongles that share the load. Dan Cvrcek, CTO of S-CRIB developer Smart Crib Ltd., offered schematics here that he said would allow three dongles to perform one million logins per day.

Besides doubts about whether the approach can scale to the level required by many websites, some researchers also question whether it really represents a step forward when compared to current practices. That’s because S-CRIB uses a single SHA1 iteration to convert plaintext into hashes. Given the extreme speed and modest computational requirements of SHA1, that means very few resources are needed to crack huge numbers of hashes in the event the HMAC key is somehow compromised.

“The security relies on keeping that key a secret,” Gosney explained. “If the key is compromised, then the security is about as strong as a salted SHA1, uniterated. That would be fine if you can guarantee the key will not be compromised. The problem is you can’t guarantee that.”

Other questions involve how, or if, the key is backed up. If not, that could produce big problems in the event a hardware failure destroys the key. If the key is backed up, on the other hand, the question is how to do so in a way that can’t be exploited by hackers.

Whatever the merits of currently using the S-CRIB Scrambler in production environments, it’s worth taking a look. What makes it attractive is the way it attempts to tackle one of the biggest problems on the Internet—users who insist on choosing weak passwords—using low cost method that requires minimal computing resources. For the time being, it’s probably safer to use straight bcrypt or another “slow” hash function to store passwords at rest, although many site administrators say the computational requirements of those schemes are too costly to be viable. It’s worth keeping an eye on alternative approaches such as the one used by S-CRIB. Eventually, one of them may make sense

via Can this $70 dongle stem the epidemic of password breaches? | Ars Technica.

Microsoft beefs up account security

Microsoft is adding a few new security features to provide more peace of mind for Microsoft Account holders.

Users will soon be able to see a recent activity log through Microsoft’s website, showing recent sign-ins, incorrect password entries, password resets, and security challenges, as well as the locations of each activity. If anything looks suspicious, users can click a “This-wasn’t-me” button to get help locking down their accounts.

Users can keep an eye on recent account activity and get help with locking down their accounts.

Microsoft also is adding more control over security notifications for certain activities, such as resetting your password or logging in from a new device. Users will still always get notifications at a primary e-mail address, but now there\’s an option to add extra phone numbers for these notifications.

Finally, Microsoft will provide a fallback for users who’ve enabled two-step verification on their accounts. Typically, two-step verification requires a phone number, an e-mail address, or an authenticator app as well as a password to log in on an unrecognized device, but now Microsoft will let users create a recovery code to access their accounts when other options aren’t available. Microsoft suggests writing the code down on a piece of paper and placing it somewhere safe, rather than storing it on a device.

A recovery code acts as a fallback for users with two-step verification.

The added security measures are necessary for Microsoft in its new push as a “devices-and-services” company. Microsoft wants to carve out a bigger role for online services such as Office 365, SkyDrive, Outlook.com, and Xbox, working across multiple platforms. With all of these products tied to a single Microsoft login, the potential security headaches only get bigger, so Microsoft needs to ramp up its security efforts accordingly.

The new security features may not be immediately visible, but should roll out to all users over the next couple of days.

via Microsoft beefs up account security | PCWorld.

Just how bad are the top 100 passwords from the Adobe hack? (Hint: think really, really bad)

Just how bad are the top 100 passwords from the Adobe hack? (Hint: think really, really bad) | ZDNet

It’s well-known that people often pick easy to remember but easy to crack passwords to protect their accounts. Thanks to the work of one password expert, it’s now thought that millions of Adobe customers were among those with a taste for terrible passwords too.

Adobe recently revealed that the security breach which affected the company last month turned out to have involved at least 38 million Adobe IDs and encrypted passwords, rather than the 2.9 million the company originally reported.

But the 38 million figure only related to active accounts. Along with the source code for products such as ColdFusion, the hackers made off with and published a file that contained over more than million user records for inactive as well as active accounts, which included more than 130 million encrypted passwords.

Read this

Do unseen passwords really need masking?

Password\’s rotten core not complexity but reuse

Could ‘honeywords’ help stop high-profile password breaches?

One password cracked and your business is history

Google unveils 5-year roadmap for strong authentication

Although Adobe has said the passwords were encrypted, it appears the way Adobe did that was not enough to prevent passwords expert and founder of the security firm Stricture Consulting Group, Jeremi Gosney, from deriving them to reveal the most commonly used passwords, which he published over the weekend, spanning around six million or just under five percent of the 130 million password list. (How he derived them is explained below.)

The most popular password, used by nearly two million Adobe customers, is “123456”. There aren\’t any surprises there though; the Yahoo leak of 450,000 passwords last year, and other similar breaches, have also revealed the same password as a user favourite.

The others in the Adobe top 10 are equally poor. The second most popular was “123456789”, used for 446,162 accounts, followed by “password” common to 345,843 accounts, “adobe123” used in 211,659 accounts, “12345678” used for 201,580 accounts, followed by “qwerty”, “1234567”, “111111”, “photoshop” and “123123”.

Gosney notes that since he doesn’t have the key Adobe used to encrypt the passwords of 130,324,429 users — and since Adobe is still blocking access to its services until owners reset their passwords — it’s impossible to say with certainty that the list is entirely accurate, but he says he’s nonetheless “fairly confident” of its accuracy.

Gosney confirmed the source of the analysis was a file containing the passwords was leaked on Anonnews last week. So how was it all possible? Here’s what he told ZDNet:

See, the passwords in this leak are were all encrypted with the same key. Without that key, we cannot crack a single password. But as soon as we have that key, we can instantly crack all of them. So for this particular leak, we’re not trying to crack individual passwords — we’re trying to crack the encryption key.

Adobe encrypted the passwords with 3DES in ECB mode. 3DES itself isn’t a terrible cipher, depending on which key option was used. But ECB mode is really bad, because it leaks information about what was encrypted. Basically, ECB mode works by dividing a message into blocks, and then encrypting each block individually. This means that the same plaintext block will always result in the same ciphertext block when encrypted with the same key.

Analysing patters in the ciphertext along with known plaintext-ciphertext pairs allows you to learn quite a bit of information about the encrypted data. In this case, we had lots of known plaintext-ciphertext pairs because a lot of people were affected by this breach, myself included.

The top 100 list we published was based solely on manual analysis of the ciphertexts, combined with manual analysis of the user-supplied password hints for each password. This enabled us to make highly educated guesses at what each of the passwords might be, but we won’t know for sure until the encryption key is recovered.

The password hints were the most telling. An overwhelming number of people took the concept of a password hint too literally, and flat-out provided the password itself as the hint. By analysing thousands of password hints per ciphertext, and matching that information with what we know about the ciphertext thanks to ECB mode, we are able to determine a number of passwords with a reasonable degree of certainty. It took about three hours to determine what the top 100 passwords were with this method.

Some will conclude that ECB mode was obviously Adobe’s downfall here, but the real point is that the passwords never should have been encrypted in the first place. They should have been hashed, using a proper password hashing function. It sounds like Adobe is in the process of remedying this, however, as they state that their new solution uses over one thousand iterations of salted SHA-256.

Full Story: Just how bad are the top 100 passwords from the Adobe hack? (Hint: think really, really bad) | ZDNet.