4
$\begingroup$

There is the (relatively) recent tag , but most questions about the subject lack it. Many of them are tagged + . There is also which is almost the same thing as the first.

How should such questions be tagged and do we need both and - or either?

$\endgroup$
  • 2
    $\begingroup$ In my humble opinion, we need the separation between pbkdf and password-hashing. I think more of password-hashing as the goal to protect the password, while in pbkdf the goal is to generate another password (unless I am wrong). Also as you said password + hash should be replaced (when together) by password-hashing. My 2 sestertii. :) $\endgroup$ – Biv Jun 15 '16 at 13:58
  • $\begingroup$ @Biv, you mean "generate another" key rather than password? Also, I did not suggest replacing password+hash with password-hashing. If anything, I think the tags would all apply. $\endgroup$ – otus Jun 17 '16 at 9:48
  • $\begingroup$ @Biv: While the nominal purpose of password-based key derivation functions (PBKDF) is to, well, derive encryption keys from passwords, they're also commonly used to derive storable authentication tokens ("password hashes") from passwords as well. Given that the two tasks have essentially the same set of solutions, I do think that having separate tags for them seems a bit awkward. Maybe we should just merge both of them (and password-based-encryption) into a single generic password-based tag? Although that would probably get confused with passwords... $\endgroup$ – Ilmari Karonen Jun 17 '16 at 9:52
4
$\begingroup$

Let me start with a summary of the current situation as I see it. As far as I'm aware of, we currently have the following password-related tags (listed with their tag wiki excerpts):

  • (236 questions)
    "Passwords are secret keys which human beings can memorize."
  • (52 questions)
    "Encryption using a key derived from a password or passphrase entered by the user."
  • (15 questions)
    "A PBKDF is a Password Based Key Derivation Function, which can be used to derive key data or derive a "password hash" from a salt and password."
  • (12 questions, no tag wiki yet)

We also have as a natural pair for , as well as a bunch of tags for specific KDFs (including , , and on the PBKDF side, and on the KBKDF side) and also the generic (which is a synonym for ).

What we conspicuously don't have, with the notable exception of , is any specific tags for password-related things other than hashing / key derivation. We don't seem to have anything like e.g. , , or even — all of those topics are, apparently, just lumped under the generic tag.


The issue raised by otus is that, from the answerer's point of view, and are effectively synonymous: while the tasks of deriving an encryption key and deriving an authentication token from a password are superficially different, the solutions to both turn out to be exactly the same.

(I would also like to point out that also significantly overlaps , given that the standard — and practically speaking, the only generally secure — way to implement password-based encryption is to first derive an encryption key from the password with a PBKDF. In fact, it seems to me that password hashing and password-based encryption together basically cover the typical range of uses for PBKDFs.)

The obvious solution, given that we already have a comprehensive set of tags for various kinds of KDFs, would be to make the new tag a synonym for . The current tag wiki for even explicitly says that it covers password hashing as well.

The obvious problem with the solution is tag "PBKDF" is an obscure acronym. A tag synonym could guide askers into using it, but people Googling for information about password hashing are unlikely to find it.

On the other hand, Google doesn't just look at tags (and neither does SE's internal search). Out of the 12 posts currently tagged with , only two don't currently contain both of the words "password" and "hash" in the question body. (And the latter one has them both in answers at least; I have absolutely no idea what the former question is about, so I can't tell if it's correctly tagged or not.) So, even with a tag synonym, users Googling for "password hash" should still find them.


Other possible solutions might include:

I don't think either of these would be a horrible choice, or even obviously worse than the proposed merge. The current situation does make our tag structure a bit redundant and harder to navigate, but such redundancy and occasional inconsistency is an inevitable feature of any "folksonomy" tagging system.


Given all this, I'd be personally inclined to just leave things as they are for now, and see how our tagging system will develop naturally.

This does mean that we'll be (for the time being) stuck with both and , but I suspect that, even though those tags may seem all but synonymous in terms of their answers, most question askers will in fact naturally and consistently pick one or the other (and this distinction may even be useful for tailoring the answers to match the asker's background). Our search systems (both the standard SE search box, as well as the similarity search used to find "related questions", and of course external search engines like Google) are generally smart enough to cope with this.

Obviously, we should come up with a tag wiki (or at least a summary) for . And, arguably, we should consider retagging some of our existing questions currently tagged with + to use the tag (with or without the generic ).

In fact, I'd argue that (assuming that we want to keep or something like it around at all) this would be an improvement anyway. The tag is quite badly overused, and password hashing does not, in my opinion, really fall under its core scope. So moving those questions from to a more specific tag, whatever its name may end up being, would seem a good thing to me.

$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .