: Feedback on technical blog post I've recently composed a blog post about World of Warcraft Authenticators and would love for some feedback as per the quality of writing. Obviously no matter how

I found the white text on the black background to be very difficult for me to read your post. I did my best to get through the content and thought the material itself was fine, but the choice of text and background made it strenuous for me to stay focused.

I cannot comment on if the material was concise, because I don't know much about the material in general. But if you wanted brevity you could probably cut it in half in order to get the information you want delivered. I would suggest that you might want to cut it in half anyway, and do a "Part 1", "Part 2", maybe even more parts, and make a short series. That way you get extra posts out of one topic.

HTH

---

(0)

This started short, and then got long pretty quickly. Feel free to use as many of my suggestions as you want, or none at all. :)

1) First off, I find your site VERY hard to read. White on black works for a small group of people, but dark on light is more universally accessible according to every usability study... ever. I also had trouble distinguishing bolded text from non-bolded. Outside the scope of what you're asking, but something to think about for later.

2) Abbreviating "number" as "no" is pretty jarring. You're not space-constrained (a la Twitter), so you should probably write the whole number out.

3) You've got some missing commas, missing apostrophes, and a missing letter. I fixed them in my reworded sections.

4) I've never played WoW, but found the article interesting nonetheless. :)

Now for some re-phrasing:

Original:
Since time is universal and the serial no never changes both the WoW server, and the device now have access to the two same variables.

Reworded:
Since time is universal and the serial no never changes, the WoW server and the device both have access to the same two variables. ("two same" is more awkward than "same two")

--

Original:
The server (when you log in) and the authenticator (when you press the button) both generate a code based on the current time and the serial no. Using these both parties concatenate them together so they end up with a sum of all of those values like so:

Reworded:
The login server and authentication fob both generate a code based on the current time and serial number. These are then concantenated together to come up with one long sequence of numbers, like so:

Note: I know what concantenate means, but a lot of people don't. You could use a word like "stitch" instead, depending on who your audience is. "These are then stitched together to come up with..."

--

*Sum of know[N] values = [Current Time] + [Authenticator Serial No]

For example:

Known values = 12:37 + 1412668222

gives you the following sequence of numbers:

[numbers]

This sequence could be generated by the login server or the authenticator fob for any given time.*

--

Original:
The small problem with this is if anyone could capture this number, by looking at your screen, keylogging, phishing or any number of other attacks it would be trivial pick apart the separate values and modify it so that it would work any time they required.

Reword:
The problem with this is that this number can be captured by anyone through a variety of methods: looking at your screen, installing a keylogger, phishing, or any number of other attacks. [Usually, if something is trivial, you don't need to say it, so omit the last part of this pharagraph.]

--

"So if I was somehow able to obtain someones log-in code as above, and I knew what its separate components were. I could just take off the first 4 digits (1237) and substitute in the current time whenever I wanted to generate a verified code."

Redundant.

--

Content:
"To mitigate this the number is encrypted using either DES, 3DES or AES as supported by the device which will turn it into something meaningless, such as: 63634545."

Do you know this for sure? It seems more likely that they'd use a one-way hashing algorithm instead.

--

Original:
To mitigate the user taking a while to submit their code it's likely the WoW server will accept a number of codes corresponding to a couple of minutes prior the actual time.

Reword:
To mitigate the user taking a while to submit their code it's likely the WoW server will accept a range of numbers, from a couple of minutes prior to the actual time.

--

Original:
Therefore I hope I've demystified how these devices work, and shown how its possible to manufacture these devices for mere pennies whilst thwarting many sophisticated attempts to gain access to users WoW accounts.

Reword:
I hope I've explained how these devices work, and shown how it's possible to manufacture these devices for pennies while thwarting a range of attack vectors.

---

(0)

Is it easy to follow?

I didn't really find this paragraph to be very clear.

So if I was somehow able to obtain someones log-in code as above, and I knew what its separate components were. I could just take off the first 4 digits (1237) and substitute in the current time whenever I wanted to generate a verified code.

Also, I wasn't sure why you had the scare quotes around synchronize.

When you first receive your device you must "synchronise" your online account with the serial no

You generally have to enter at least one or two codes in a row in order to synchronize the authenticator, because it uses a time based function, rather than the actual date and time (it updates every 30 seconds in reality), and the server needs to determine where you are in the sequence of valid serial numbers. So it is actually synchronizing something and as such doesn't need the scare quotes.

You also have a few single-sentence paragraphs which don't seem to convey a complete thought you might consider combining, for instance the one beginning "To mitigate this. . ."

I did enjoy reading it, aside from the middle where the information seemed to be quite disjoint, and it does have the potential to be a great article after some work.

---

(0)