I don't agree with the author's premise wrt to usernames.
Often, you will login with a username, but the password recovery form will only accept an email. You might be able to correlate these two if you have a lot of data from other, external attacks, but unless if I noticed correlation between recovered passwords and account break-ins, I wouldn't worry about this.
There's a security tradeoff, but sometimes security must be risked in the name of functionality, or you'll have a lame product. Or, you can have both security and functionality, but to the detriment of UX.
Take leaderboards for example. If you have a leaderboard for your app/game, you'll expose user's username (and thus, sign-in name, as is often the case). You could mitigate this by: having a separate login name (ala steam), or using an email (which exposes people to the recovery exploit), but it doesn't make the UX any better.
In the end, I'd say trying to protect against username/email guessing attacks is probably unnecessary. There are better ways to approach security.
Often, you will login with a username, but the password recovery form will only accept an email. You might be able to correlate these two if you have a lot of data from other, external attacks, but unless if I noticed correlation between recovered passwords and account break-ins, I wouldn't worry about this.
There's a security tradeoff, but sometimes security must be risked in the name of functionality, or you'll have a lame product. Or, you can have both security and functionality, but to the detriment of UX.
Take leaderboards for example. If you have a leaderboard for your app/game, you'll expose user's username (and thus, sign-in name, as is often the case). You could mitigate this by: having a separate login name (ala steam), or using an email (which exposes people to the recovery exploit), but it doesn't make the UX any better.
In the end, I'd say trying to protect against username/email guessing attacks is probably unnecessary. There are better ways to approach security.