This evening, I was looking at a record of recent failed attempts to log into this 'blog. I found that relatively few attempts tried to do so with the popular username of admin, whereäs by far the majority were with the username oeconomist (that it to say with the second-level domain name). There is not and never has been an account here with username oeconomist; the would-be intruder was guessing mistakenly — but not unreasonably. If my logs are representative, then having an account name match a second-level domain name is less secure than having it be admin. With people avoiding admin, it is natural for crackers to try other likely candidates, including candidates whose probabilities are conditional upon the domain names.

Mind you that the reasoning of my earlier explanation of why the avoidance of admin doesn't add a discernible amount of security if passcodes are properly selected can be applied to avoiding a username that matches a domain name. An account with a known username and a well-chosen password of m+n characters is more secure than an account with a secret m-character username and an n-character password.

Choose a username that pleases you. Choose a password that is long and that looks like chaos, and make occasional changes to it.

To-day, I found myself unable to log-in to this 'blog. I got a diagnostic that I were entering the wrong password. I don't want to burden my readers with a detailed retelling, but what had actually happened was that an up-date of WordPress rejected my password — it wasn't that I were entering the wrong password; it was that the password that I was entering was now prohibitted.

On top of the login code misreporting the problem, the code for resetting the password wouldn't tell me why my password was being rejected. But it was rejected for containing a particular sub-string; and when I removed that sub-string, the password was then accepted.

If you understand passcodes (perhaps in part from reading my previous entry in which they were discussed), then you should see that there is something literally stupid in the WordPress software. Let's say that the forbidden sub-string were 8675309 and that my password were X.52341-hunao-8675309.Y. If I drop the 8675309, the password becomes X.52341-hunao-.Y. That is now accepted, though it is less secure!

If a would-be intruder knew where in the original password 8675309 appeared, and knew the length of the password, then the password would effectively be p₁p₂…p₁₄8675309p₂₂p₂₃ where each p_i were an unknown character, and the new password would be p₁p₂…p₁₄p₂₂p₂₃ so that the two passwords would be equally secure! (Either way, an intruder must find a sequence of sixteen unknown characters.) But, as it is, would-be intruders wouldn't be sure that the sub-string appeared, let alone where in the code it would appear, nor how long the password were. One could, in fact, conceptualize the sub-string 8675309 as if it were a single character of extraordinary length (a macro-character) and of great popularity which character might appear within a string of equal or greater length, in which case prohibiting the sub-string would be rather like prohibiting the use of E.

That's not to say that common sub-strings should simply be accepted as passwords or within passwords. A great many systems have been hacked because someone foolishly used passwords such as password, root, or batman. But, instead of rejecting a password because it contained a popular sub-string, the software could, for example, test to see whether the password would be secure if the sub-string were excised, in which case it should be at least slightly more secure if the sub-string were retained.

(Note that this approach works with popular sub-strings of any length, including those of just one character! In fact, when there is no upper-limit on the length of passcodes, they may be securely constructed of nothing but popular sub-strings each of which has multiple characters; a secure password could be made by concatenating ten or more of the one hundred most popular passcodes. Mathematically, the problem of using just one popular passcode is fundamentally the same as that of using a short passcode!)

Sometimes, it's smart programming to write stupid programs, because the costs of designing, implementing, and maintaining more sophisticated software out-weigh the benefits. But, here, the WordPress programmers have opted for cheapness in a way that needlessly thwarts and insults some users, and can actually make systems less secure in those cases. (And the poor diagnostics are simply inexcusable.)

Those managing 'blogs are frequently told that the administrative account should not have a username of admin nor of administrator.[1] Indeed, 'bots attacking this 'blog try the username admin multiple times every day. None-the-less, I think that concern about easily guessed usernames is quite misplaced.

Ordinary access to an account requires two pieces of identification, the username and a passcode. We can conceptualize these jointly as a single string, the first part of which is practically fixed, the second part of which is changeable. For example, if one had the username admin and the passcode h3Ll0p0p3y3, then the string would be adminh3Ll0p0p3y3 Some might imagine that two strings represent two hoops and therefore more security; but, actually, each character is a hoop. If usernames and passcodes were equally secure, then the username-passcode pairs kelsey5 dO0DL3bug and kelsey 5dO0DL3bug would be perfectly equivalent as far as security were concerned. So we can imagine the two strings concatenated, so long as we remember that one set of its characters are unchangeable, while the others may be changed. In general, the form of the string can be conceptualized as u₁u₂…u_mp₁p₂…p_n where each u_i represents an unchangeable username character and each p_j represents a changeable passcode character. Now, if we simply know that the administrative account username is admin adminp₁p₂…p_n unauthorized access is a matter of guessing the characters of the passcode, without knowing how many they might be. (How passcodes are stored may limit or effectively limit the length of passcodes, but this will typically not have much effect unless those limits are very tight.) On the other hand, if the administrative username is completely unknown, then the string is the apparently more mysterious u₁u₂…u_mp₁p₂…p_n That might seem significantly more secure. However, the number of characters in the passcode is unknown to the opponent, and u₁u₂…u_m-kp₁p₂…p_n+k is more secure for all 0 < k ≤ m,[2] because usernames are unchangeable. (Were usernames as changeable as are passcode, then the two would be equally secure.) And adminp₁p₂…p_n+m is more secure than u₁u₂…u_mp₁p₂…p_n

So real security here is to be found in long and strong passcodes, for which secret usernames are poor substitutes, and one can easily compensate for a readily guessed username by having a stronger passcode.

[0 (2016:03/30, 04/09)] I've fleshed-out this entry a bit, in an attempt to make in more easily understood.

[1] See, for example, the entry for 23 March at the Wordfence 'blog.

[2] The case k = m represents a zero-length username, which really is to say no username at all. It would be quite possible to create a system with just passcodes and no distinct usernames — or, equivalently, a system with very changeable usernames and no passcodes — though this would present some practical difficulties.