Language Selection

English French German Italian Portuguese Spanish

Voluntary Disclosure Is the Threat to Password Security

Filed under
Security

Computers can remember complex bits of data effortlessly, but people routinely fumble that task. Naturally, one of the big trends in computing security is making users memorize complex passwords -- then regularly wipe those from their memory in favor of equally obscure replacements.

To judge from the stern advice handed out by banks, Internet providers and information technology departments -- often, I suspect, after prodding by accounting departments and liability lawyers who don't want to be blamed for a security breach -- computer security hinges almost entirely on you choosing a string of letters, numbers and symbols in an order that has no correlation to any word or phrase that has ever been spoken or written in English or any other language.

That's fiction. First, while avoiding obvious passwords still constitutes a common-sense defense, that won't stop most password theft attempts these days. Second, forcing people to choose the most obscure passwords possible, then choose new ones every few months, is more likely to grease the skids for a successful compromise of those users' accounts.

This is because passwords aren't stolen in ways you might expect; a bad guy doesn't sit down in front of your computer and start typing in guess after guess until he succeeds. In the real world, accounts are usually cracked in two ways -- only one of which can be slowed or stopped by the use of a sufficiently inscrutable password.

One is to get access to the computer that stores users' login info. If the master password file stored on that machine is encrypted -- it should be, but sometimes is not -- the attacker then runs a password-cracking program to break that encoding. Otherwise, he or she can read the file as-is.

The other method relies on someone surrendering a password voluntarily. For example, an attacker can hide a program on a victim's computer to record each tap of the keyboard -- often by exploiting an old, long-since-patched vulnerability in Windows or by hiding the "keystroke logger" in a tempting download.

Or the attacker can just ask nicely for the password -- what's called "social engineering." The victims can be technical staff at a bank or an Internet provider who get a call from somebody claiming to be a colleague elsewhere in the company. Or the victims can be individual users who receive "phishing" e-mails imploring them to verify their account information by clicking on a link to a phony Web site done up to appear like that of a trusted institution.

The quality of a password matters only against the first type of attack -- the brute-force, code-breaking assault, which will hit pay dirt more quickly if stored passwords appear in dictionaries.

That's why security experts tell password creators to avoid using real words or names, even when altered by substituting letters with similar-looking numbers or symbols (for example, replacing "i" with "!" or "1"). One common suggestion is to use words only as ingredients -- say, by combining the first letters of names of friends or titles of favorite books.
But if an attacker employs keystroke logging or social engineering, it doesn't matter whether your password is "password" or "92nkkcx-j1!" Even the most inscrutable login offers no defense against those tactics -- which are what most attackers seem to employ these days.

"If you go back 10 years ago, password cracking was the way to do things," said Marty Lindner, a senior member of the technical staff at the CERT Coordination Center, the network-security center founded at Carnegie Mellon University in 1988. Now, however, he said that phishing and other social engineering attacks are "far more prevalent, far more devastating than anything else."

Granted, getting actual numbers on how people's accounts were broken into is difficult -- few institutions want to discuss how some teenage hacker managed to own them. But there's no arguing that phishing and spyware attacks are only getting worse, and understandably so; why should an Internet con artist waste time mastering password-cracking routines when there are smoother roads into the bank vault?

And yet too many companies seem content to rely on password Puritanism as their response. Sometimes it's just silly -- for example, when some newspaper sites force readers to choose passwords with at least one number.

But more often, it's self-defeating. When users are pushed to remember too-obscure passwords, they'll start writing them down on Post-It notes stuck to a monitor or (worse yet) start reusing passwords among multiple high-value accounts. Worst of all is the policy of some companies and financial institutions to require users to change passwords every 30 or 90 days.

Not only do those periods still offer more than enough time for a minimally competent hacker to swipe an account login, the regular changing of passwords can easily soften up people for social engineering attacks.

Think of what happens every time a user must change a password -- or inevitably forgets the login of the month or the quarter: They'll have to go to a Web page or call up a help desk to get the password reset. That interaction represents a regularly scheduled opportunity for an attacker to try to step in and impersonate either party.

A few weeks ago, confronted by an obscure Web-mail login subject to one of these inane password-expiration rules, I called the support number listed on that site to have my password reset. (No, I won't name the firm involved). I expected to have the new login e-mailed to me -- but instead the helpful fellow on the other end of the line just read it to me over the phone, making no attempt to verify my identity.

If I'd been interested in stealing access to somebody else's account, I could have had a lot of fun. Instead, I could only wonder why we keep wasting our time with these illusory measures.
There are real problems with network security these days. But treating customers as if they were reprogrammable robots won't solve any of them.

By Rob Pegoraro.

More in Tux Machines

Security Leftovers

  • Security updates for Tuesday
  • Initial Retpoline Support Added To LLVM For Spectre v2 Mitigation
    The LLVM code has been merged to mainline for the Retpoline x86 mitigation technique for Spectre Variant 2. This will be back-ported to LLVM 6.0 and also LLVM 5.0 with an immediate point release expected to get this patched compiler out in the wild. The compiler-side work -- similar to GCC's Retpoline code -- is to avoid generating code where an indirect branch could have its prediction poisoned by a rogue actor. The Retpoline support uses indirect calls in a non-speculatable way.
  • Teen Hacker Who Social Engineered His Way Into Top-Level US Government Officials' Accounts Pleads Guilty To Ten Charges
    The teenage hacker who tore CIA director John Brennan a new AOL-hole is awaiting sentencing in the UK. Kane Gamble, the apparent founder of hacker collective Crackas With Attitude, was able to access classified documents Brennan has forwarded to his personal email account by posing as a Verizon tech. Social engineering is still the best hacking tool. It's something anyone anywhere can do. If you do it well, a whole host of supposedly-secured information can be had, thanks to multiple entities relying on the same personal identifiers to "verify" the social engineer they're talking to is the person who owns accounts they're granting access to. Despite claiming he was motivated by American injustices perpetrated around the world (Palestine is namechecked in the teen's multiple mini-manifestos), a lot of what Gamble participated in was plain, old fashioned harassment.
  • The Guardian view on cyberwar: an urgent problem [Ed: Lists several attacks by Microsoft Windows (but names neither)]
    The first known, and perhaps the most successful of these, was the joint US/Israeli Stuxnet attack on the Iranian nuclear programme in 2009. Since then there has been increasing evidence of attacks of this sort by Russia – against Estonia in 2009, and then against Ukraine, where tens of thousands of attacks on everything from power supplies to voting machines have opened an under-reported front in an under-reported war. Across the Baltic, the Swedish government has just announced a beefed-up programme of civil defence, of which the most substantial part will be an attempt to protect its software and networks from attacks. Meanwhile, North Korean state hackers are blamed by western intelligence services for the WannaCry ransomware attacks which last year shut down several NHS hospitals in the UK. Persistent reports suggest the US has interfered in this way with North Korea’s nuclear missile programme.
  • Reproducible Builds: Weekly report #143
  • Don’t Install Meltdown And Spectre Patches, Intel Warns It Would Increase System Reebots
  • On that Spectre mitigations discussion
    By now, almost everybody has probably seen the press coverage of Linus Torvalds's remarks about one of the patches addressing Spectre variant 2. Less noted, but much more informative, is David Woodhouse's response on why those patches are the way they are.

Tails 3.5 Anonymous OS Released to Mitigate Spectre Vulnerability for AMD CPUs

Tails, the open-source Linux-based operating system designed to protect user's privacy while surfing the Internet, also known as Anonymous OS, was updated today to version 3.5. Coming only two weeks after the Tails 3.4 release, which included patches for the Meltdown and Spectre security vulnerabilities publicly disclosed earlier this month, today's Tails 3.5 update is here to bump the Linux kernel to version 4.14.13 and include the microcode firmware for AMD CPUs to mitigate the Spectre flaw. Read more

Graphics: Freedreno, Gallium3D, AMDGPU, RadeonSI, Mesa

  • Code Aurora Working On Adreno 6xx Support For Freedreno
    The Qualcomm-aligned Code Aurora is working on supporting the latest-generation Adreno A6xx graphics hardware with the open-source Freedreno+MSM driver stack.
  • Work Revised On Adding SPIR-V Support To Clover Gallium3D
    Last May we reported on a Nouveau developer adding SPIR-V support to Gallium3D's OpenCL state tracker. Finally the better part of one year later, Pierre Moreau is ready with the second version of these patches to accept this IR associated with Vulkan / OpenCL 2.1+ within Clover.
  • Trying Out DRM-Next For Linux 4.16 With AMDGPU On Polaris & Vega
    I have spent some time this weekend trying out the DRM-Next code slated for inclusion in Linux 4.16 when its merge window opens next week. The DRM-Next state of the AMDGPU driver appears to be in good shape, at least for the RX 580 and RX Vega cards used for my initial testing.
  • RadeonSI NIR Back-End Picks Up Support For More OpenGL Extensions
    It was just a few days ago that Valve Linux developer Timothy Arceri enabled GLSL 4.50 support for RadeonSI's NIR back-end after previously taking care of tessellation shaders and other requirements. Now he has taken to implementing some other extensions in RadeonSI's NIR code-path.
  • mesa 18.0-0-rc1
    The first release candidate for Mesa 18.0.0 is now available. The plan is to have one release candidate every Friday, until the anticipated final release on 9th February 2018. The expectation is that the 17.3 branch will remain alive with bi-weekly releases until the 18.0.1 release. NOTE: Building the SWR with LLVM 3.9 is currently not possible. Please use newer LLVM version until the issue is resolved. Here are the people which helped shape the current release.
  • Mesa 18.0 Now Under Feature Freeze With 18.0-RC1 Premiere
    Feature development on Mesa 18.0 has now ended with the release today of 18.0-RC1 following the code-base being branched. Emil Velikov of Collabora just announced the availability of Mesa 18.0-RC1. As usual, he's planning on weekly release candidates until the 18.0.0 stable release is ready to ship. Velikov tentatively expects to ship Mesa 18.0.0 around 9 February, but as we know from past releases, it might end up slipping by some days.

Using Dual 4K Monitors Stacked With GNOME

The setup for my main production system that is still on Fedora Workstation 26 with GNOME Shell 3.24.3 has been working out fine. The two displays are the ASUS MG28UQ monitors that work out well on their own and do work with AMDGPU FreeSync on Linux. A GeForce GTX 1050 Ti is enough to power the dual 3840 x 2160 displays for desktop tasks mostly limited to many terminals, Firefox, Chrome, Thunderbird, and other GNOME desktop applications. Certainly that lower-end Pascal GPU isn't fast enough for 4K gaming, but it's not like I have the time for any gaming and for a purely desktop system it's working out fine paired with the 387.34 proprietary driver on Fedora 26 paired with Linux 4.14. Read more