Member Avatar for rproffitt

Last month, Facebook admitted to storing million of Facebook passwords in plaintext.
The Verge Apr 18, 2019

We see students being taught login systems here and a recurring mistake is passwords being stored in databases. It appears that CompSci courses teach bad practices early and as we know it's hard to unlearn what you learn earlier.

Further reading seems to indicate these passwords may have collected via logging.
"But as Krebs on Security first reported, various errors seem to have caused Facebook’s systems to log some passwords in plain text since as early as 2012."

I'm been chided for pointing this out from time to time but the mistake happens over and over and in very big companies.

Edited by rproffitt because: Formatting change.
  • 4 Contributors
  • 3 Replies
  • 3K Views
  • 3 Months Discussion Span
  • Latest Post Latest Post by AndreRet

Dani AI

Generated

is right: these failures often start in the pipeline, not the database. Treat passwords like hazardous material: accept only over TLS, never echo them back, and prevent them from ever touching logs, crash reports, APM traces, or analytics payloads. Use an allowlist-based logger and explicitly redact sensitive fields. (cheatsheetseries.owasp.org)

A storage recipe that will stand up to scrutiny:

  • Hash on the server with Argon2id and a per-user random salt. Tune cost so a single hash takes well under a second on your hardware; OWASP’s minimums (about 19 MiB memory, time cost 2, parallelism 1) are a solid floor. If Argon2id is unavailable, use scrypt or (legacy) bcrypt with a high work factor. Store the algorithm, salt, and parameters alongside the hash to enable seamless rehashing later. (cheatsheetseries.owasp.org, rfc-editor.org)
  • Consider a pepper: perform an additional keyed hash using a secret stored in an HSM or KMS (separate from the DB). NIST explicitly recommends this as defense in depth. (pages.nist.gov)
  • Follow modern password policy: minimum length at least 8 (prefer 15+), allow long passphrases and paste/password managers, no composition rules, check new passwords against a blocklist of commonly used or breached values, and enforce online rate limiting. Salted, iterated hashing is required. (pages.nist.gov)

Example Argon2id usage (Node.js):

const argon2 = require('argon2');

const params = { type: argon2.argon2id, memoryCost: 19456, timeCost: 2, parallelism: 1 };

async function hashPassword(plain) {
  return argon2.hash(plain, params); // includes a random salt
}

async function verifyPassword(storedHash, candidate) {
  const ok = await argon2.verify(storedHash, candidate); // constant-time compare
  if (ok && argon2.needsRehash(storedHash, params)) {
    const upgraded = await argon2.hash(candidate, params); /* persist upgraded */
  }
  return ok;
}

This aligns with what emphasized: we cannot make attacks impossible, but we can make them impractical and keep plaintext out of reach, including from our own logs. (cheatsheetseries.owasp.org)

Recommended Answers

All 3 Replies

Member Avatar for happygeek

It just got worse. As I wrote at Forbes yesterday, FB has now confirmed (albeit very quietly as an update to a month old post and on the day the Mueller report was published) that millions of Instagram passwords were stored in plain text as well...

commented: The number of textbooks or assignments with login code teach them badly. Off to change my Insta+FB passwords. +15
Member Avatar for quickmarket

This is a fact not only for facebook. P.S. I dont know why everybody are talking about privacy but in the second you connect to the internet there is no longer privacy ...Do you remember the movie that an american who escaped in Russia because of all things he revealed and that we are under the eye of all governments.,..... Not only USA, but all... So.... Privacy ?!.... That is why,,, personal info in internet NO, should not be even at your device, infact if you want to store something digital, you should have one device that will be never conected to the internet. Payments only with electronic cards that you can uplaod certain amount and no one cant get all of your money only the amount for online paymens... This topic is realy endless... So I can say that no big deal. Hackers cant be stoped from anyone... If those are killed new ones will be born and that is it...I mean the government hackers not the rest

Edited by quickmarket
Member Avatar for AndreRet

I cannot agree more. Ultimately it is our responsability as developers to see that we secure all and any sensitive data that our applications deal with at the moment such data is received.

I think the problem is as pointed out, you have been taught that 1 + 1 = 2 and that is that, let's stick to this format no matter how many times we read about the dangers involved in storing passwords, credit card numbers, personal detail in plain text or even in old faithful MD5. I suppose once we see the MD5 scrabble we think that no one will make head or tails of this and we are safe, you are so wrong!

I will see if I can spare a bit of time to post a full on solution to app security, something I worked on based from many a post around this subject. Fact of matter is however that no matter what we do, if a hacker wants in, they will get in. It is totally up to us to make it as difficult as possible for them to sniff our data.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.