Two days after an [article by Brian Krebs disclosed]() that hundreds of millions of Facebook account passwords had been stored in plain text for years, Facebook released a [statement]() indicating they hash and salt passwords, more or less in accordance with industry best practice. Plain text storage of credentials is a fairly egregious security misstep, but there's a variety of other ways credential security can fail. Given the trend toward sharp increase in third party credential mishandling in recent years, we'd like to take a look at some of the other ways companies handling user data can leave users insecure, irrespective of password length, complexity, or obscure security questions. ### Outdated hashes Not every hashing algorithm provides the same degree of security, and many large scale third-party breaches have occurred at companies using deprecated algorithms, or in some instances, none at all. The most common algorithm for many years, [MD5](), was shown to be insecure via single block collision in 2010, and therefore inappropriate for most security uses. MD5 weaknesses were further underlined when Microsoft published that the authors of Flame malware used MD5 vulnerabilities to forge a Windows certificate. Despite these issues, MD5 was still widely used in password hashing and allowed for attackers to easily crack exfiltrated credentials, as seen with the [2013 Yahoo breach](). Institutional inertia with updating hashes can dramatically increase the end user impact of a breach, as seen in the [haveibeenpwned list]() of data breaches that show frequent use of MD5. Organizations with a serious commitment to data handling best practices should be using either [bcrypt]() or [scrypt]() for secure credential storage. ### Misconfigured servers Cloud servers are typically a great way for enterprises to reduce cost and increase speed of infrastructure rollout. Security on an assortment of cloud services, however, can have sub-optimal default settings, or rely on users to implement security solutions. As a result, misconfigured servers have resulted in large scale data loss in a variety of settings. (While typically referred to as a breach after-the-fact, it's an inappropriate descriptor due to the lack of any fortifications to be breached.) In February of this year, [Dow Jones exposed]() 4.4GB of sensitive human targeting data simply by failing to make the AWS server the data was stored on non-public. While not indexed by search engines, threat actors with dedicated crawlers could trivially locate and exfiltrate the data in question. This sort of vulnerability of inaction is more common than most users think, and can be as impactful as an actual breach. [Godaddy exposed]() 31,000 of its own server configurations in this way, and personal information from voter databases has been repeatedly exposed, [most recently in 2017.]() With third-party service providers forming an integral part of most organizations' infrastructure, we should expect this sort of "breach" to increase in frequency. ### Security questions (with no other validation) Common in enterprise financial platforms, questions about a user's personal life started as a well-meaning account validation practice that was quickly proven as impractical for securing data. Cementing their reputation for poor security, Experian was noted for having an exceptionally poor implementation of security questions for account validation. While typically these questions are defined by end users and/or take unstructured input for the answers, [Experian]() used unchangeable questions set only by them, based on their own data holdings on users' personal information (regardless of accuracy), and made the answers trivially searchable, such as past addresses or date of birth. Security questions might still hold a modicum of security if they allow free input for both the question and the answer, and are not used as a primary account validation method. However, proliferation of personal information online makes use of security questions largely a bad call. ### Using passwords at all? What if the fundamental problem is not with handling passwords, but using passwords at all? Some researchers think that long-standing security problems involving passwords are baked into the design of using passwords to authenticate. Hardware-based, passwordless authentication can sidestep issues involving secure credential storage and transmission by requiring a physical device to generate a time-bounded authentication token. These schema are typically multifactorial designs involving smart cards, [USB keys](), [QR codes](), or biometrics. While none of these designs resolve authentication issues entirely (how do you replace a compromised thumbprint?), they can be significantly more secure than managing sending and storing a credential pair. ### It's not just about breaches As seen above, password handling by third parties carries more risk than simply a breach and exfiltration. Quite often, mishandling credential management is more problematic than direct data loss, but it also points to fundamental design flaws in an organization's infrastructure. Reducing organizations' attack surface should include a serious look at how passwords are stored, the appropriateness of an authentication scheme to a given use case, and whether your company may have outgrown passwords entirely. The next time you hear about a third-party breach and wonder, "Is my password secure?", you might also ask, "What was this organization doing with it in the first place?" The post [Facebook's plain text misstep, and other password sins]() appeared first on [Malwarebytes Labs]().

Query Builder