4 ms·

I'm sorry if I'm misunderstanding, but are you saying that application developers should not use salts at all?

• jacques_chester 13y ago
  He's saying that rolling your own with functions designed to run as fast as possible, with or without salt, is not going to give you much security. What you want is functions that run slowly, thus increasing attack cost.
  • rdtsc 13y ago
    Moreover, unless you are Schneier or tptacek don't create your own obscure slow function, use a well known one like scrypt.
    • cperciva 13y ago
      unless you are Schneier or tptacek ahem...
      • rdtsc 13y ago
        /cough cough ... or cperciva
• saidajigumi 13y ago
  I'd interpret the GP as "Application developers should not create Key Derivation Functions (KDFs)." They should choose an existing, well reviewed KDF and read up to understand its relevant best practices. For example, PBKDF2 does require a salt (as does scrypt, which relies on PBKDF2 for its implementation). It also comes with specific recommendations on the salt's minimum length. Salting an MD5 hash is pointless in the face of modern attack methods -- rice paper against a tiger.
  • Buge 13y ago
    Wouldn't individually salting MD5 still help with large databases? With a database of 1,000 users the individual salt should slow down attackers by a factor of around 1,000. If they are targeting a single user it doesn't help though.
    • rdtsc 13y ago
      It falls in line with running you ssh on an obscure port or putting your password database in .hidden/. Most likely it is just a false sense of security and security though obscurity. You are doing X,Y,Z and W and in the end you could have just used a KDF. If anything the false sense of security plays tricks on you psychologically "oh look we have put our database in a .hidden directory. Nobody we'll find it here" and that makes you not pay attention at the weakest vulnerability -- a weak algorithm or parameters of the encryption.
    • saidajigumi 13y ago
      Yes, salting has a role to play. That is not the point. The point is that use of a weak underlying Key Derivation Function makes the benefits of salting nearly moot. To fully spell it out: MD5 is a very weak KDF. I would recommend looking into the KDFs mentioned in the comments here as alternatives: PBKDF2, bcrypt, scrypt.
    • zck 13y ago
      Sure, salting definitely helps. A little. It's like telling someone being shot at to stand sideways, because their profile is smaller that way. The right thing to tell them is to get the hell off the firing range. The problem with salting is that people feel they're safe, and stop thinking about security there.
      • zimbu668 13y ago
        No they should stand head on so the bullet will take a shorter path through their body should they be hit.
    • jarrett 13y ago
• markdown 13y ago
  He's saying that if you can't use bcrypt or something like it, you should store passwords in plain text. Like a broken record people like him/her chant "no security at all is better than security by obscurity".
  • oakwhiz 13y ago
    I do not believe that this is what he is trying to say. He does not mean "use plaintext" when he says "don't salt hashes." He means "use a key derivation function."
  • jarrett 13y ago
    > if you can't use bcrypt or something like it, you should store passwords in plain text No, he's saying that if you can't use an acceptable hashing function, you shouldn't store passwords at all. But, why would you be unable to use at least one of the suggested hashing functions, anyway? It's hard for me to imagine a language or platform where none of those functions is available, excluding very simple, special-purpose systems like PLCs.
    • markdown 13y ago
      Have you heard of Google App Engine? You can't use any python module that runs C, which rules out bcrypt and its ilk.