• Customizable (password length, types of characters included, etc)
• Secure (it doesn’t communicate over the network, hence no need for SSL)
• Fully reviewable (as opposed to server-based solutions, where you have to trust the server)

The only flaw it had (as pointed out by a commenter) was the fact that passwords didn’t always include all the characters you’ve selected (ie. the checkboxes represented “possible” not “mandatory” characters, which was a little counter-intuitive).

I’ve thought about how to create passwords which included at least one character from each set. My first ideas were around generating a password, then checking that it contained at least one character from each set and if not, replacing some of the characters with ones from the missing set. However this train of thought quickly ran into problems when I had to decide which character to replace. Choosing something fixed (like the first one, last one, etc) is too predictable. If I choose a random one, I run the risk of overwriting previous change. So finally I realized that there is a simple solution: just re-generate the password until it satisfies all of the constraints. Although this might seem like a brute-force solution, in practice its speed is indistinguishable from a constant-time solution.

Below you have the new and improved YARPG:

I’ve also updated the original posting. You can get the source code for it by looking at the source of this webpage, or from my SVN repository: js_password_generator.html. Hopefully you find it useful!

Picture taken from cjc4454’s photostream with permission.

A small Windows tip: if your computer is part of a domain and all of the sudden you can’t access resources over the network (like shares, printers, etc), try changing your password.

I observed this in several networks, and although I’m not entirely sure about the reason – I suspect that it has something to do with the password expiration policy (even though the password seem to work when logging into the given system – even after a cold boot) – this workaround always seemed to work.

Update: Here is the discussion on serverfault about the problem. There were some good suggestions by Nico, but unfortunately no final solution was found as of now.

Picture taken from gemsling’s photostream with permission.

The perlmonks server has compromised and the entire user database was accessible to the attacker. What is even worse, the passwords were in cleartext (so they are directly accessible without any additional processing/cracking)! Go change your passwords now!

See more details here and here

• Passwords should be long
• The user must be able to remember the password
• It should not be composed out of words which can be found in the dictionary
• It should be different for every website / location so that if a location is compromised, the attacker can not use the obtained password to log in to other places.

Here is my solution to the problem: choose a master password and for each site generate a password from it using the password combinator (requires javascript). The advantages of this script are:

• Uses Javascript, so it runs 100% at the client side with no server communication (other than the initial page load). The server never sees any of the entered data, you can use it in offline environments (if you download it from here) and you can view the source code to make sure that it does what it claims it does.
• It can generate passwords of any length and complexity so you can tune it to what a site is able to accept.
• The generated password is completely deterministic (meaning that given the same inputs and settings it will always generate the same output), however it is very unlikely that based on the output somebody could determine the master password even if the modifier is known, since the generation is based on the SHA1 algorithm.

As I’ve mentioned above, you can use obvious things for the modifier, like the websites domain and even then the only practical attack against your master password is bruteforce. By taking a step further I’ve implemented a feature in the script which enters automatically anything after the # sign in the modifier text box, so you can head over there and generate a password for digg directly. To make it even easier, you can use the following bookmarklet (by dragging it to your Bookmarks toolbar) and when you click on it it use some javascript magic to open the password combinator with the current site already entered: SitePass

Stay safe. And remember, you can always use the random password generator to generate secure passwords which fit your needs.

One final remark: you might ask: why is this hosted on a free server? And isn’t using the bookmarklet a privacy risk, since it communicates the server what page I want to generate the password for? The answer is: I use a free server because I don’t have money currently to pay for a hosting service. Because this runs 100% client side (and again, you can look at the source to make sure of this), there is no data transmitted back to the server which would compromise your security. As for the case when you use the bookmarklet to show a prepopulated version of the page: the server again only sees the fact that you are requesting the page, anything after the # sign isn’t sent to the server, but rather interpreted by the browser.

From time to time I would like to publish a post in which I can show code snippets. However the standard <code> or <pre> tags look way too boring. Something with color stands much more out. I was thinking: if I had my own server and would host my blog there, I could add automatic syntax highlighting in no-time using GeSHi (Generic Syntax Highlighter). Then it hit me: why not use the demo hosted by them and copy the output over as HTML? It’s not as elegant or simple as having a server-side script taking care of it, but it’s better than the standard look. So here are the steps:

1. Head over to the GeSHi demo page and plug your source in. Play around with the settings until you get a satisfying result.
2. Save the resulting page (it would easier to use view source, but since this is a dynamically generated page using parameters passed with the POST method – rather than GET – it doesn’t work).
3. Open it in a text editor (like gedit or notepad) and find the style section where it says <style type=”text/css”>/* GeSHi (c) Nigel McNie 2004 (http://qbnz.com/highlighter) */ and copy it over to the blog post
4. Find the start of the code (you can do this easily by searching for style="border: 1px dotted and copy it over until the end of the code. This you can recognize by the sequence </div></li></ol>
5. Add a final </div> after the part you just copied.
6. Because I use a Blogger template which styles list items in a special way and also restricts the width of the part where the post is displayed, I have to add the following lines to the style sheet:

   div.code { overflow: auto; width: 100%; }
   div.code li {
    list-style: decimal outside;
     padding-left: 0px;
     margin-bottom: 0px;
     background: none;
   }   
   

   and also add the code class to the starting div (to do this go to the start of the part you copied and where it says class="[something]" add code, so that it looks like this: class="[something] code"

7. Enjoy

There are a few problems with this approach: (a) the biggest is that it’s a multi-step fairly complicated procedure (b) If you have multiple post with source code on your page you will have duplicate style-sheet information in your page (c) It is not recommended to include style information in-line or in the main body (the style tags you copy will end up in the body instad of the header where they should be put) (d) While copying the code you might have some weird characters appear (e) GeSHi is not perfect (for example in the code below it gets confused by the embedded javascript), but it’s the best I’ve found so far. It is a beta solution and if any of you have ideas on how to improve it, please take the time to write a comment. As a bonus you find below the source code for my Javascript random password generator (not that you couldn’t do a view source until now, but this is more accessible).

• It attempts explain about MD5 and hash algorithms in general, however it does a poor job. For example it doesn’t explain why it lends itself to brute force attacks (which btw can be explained very simply by saying: because the same string always generates the same hash, you can simply try to generate all the strings, hash each one of them and see which one gives the same hash) and while it does mention salted hashes it fails to mention what they are or the fact that they can provide protection against bruteforce attacks (if they are not known – for example supposing that only the database part of your site was compromised) and / or against pregenerated tables.
• The code provided as example is riddled with SQL injections, and while it’s true that recent versions of PHP come with magic quotes turned on by default, the article writer should at least mention this assumption, so that people who copy the code know about it and can counteract if this asumption is not true. Pear Db or precompiled queries are also not mentioned, even though they can provide a defense against SQL injection attacks.
• In the original tucows posting mentions e-mail-ing a link to users where they can change their password, however it fails to mention the security aspects of this, like it should use HTTPS, it should not be possible to easily guess it and it should expire after a certain time. I know that for many security is an afterthought, however at least think about it when you are talking about it!

To pimp my blog a little: see other password troubles with popular sites and a javascript random password generator.

• The one that Steve Gibson created can not be customized (I don’t always want ultra-long passwords)
• The one at winguides.org does not by default use HTTPS (although you can convince it manually)
• They both use a round-trip to the server and I must trust their server that it doesn’t keep logs about IP-passwords association for example. What makes it even worse in the case of the winguides.org website is the fact that they transmit all the options as GET parameters which are logged by default by the webservers (as opposed to POST parameters which are by default not logged). This means that they must make an extra effort to disable logging (at least for this part of their site), which I’m not sure they did.

My javascript offers 100% client-side generation and you can view its source code to make sure that it does what it claims it does. There is no need for HTTPS / SSL because no connection is made / no data is transmitted to the server.

Be safe and remember: password length beats password complexity most of the time.

Update: the script has been update so that it is more unobtrusive. Also I’ve published the source code for those who don’t want to search through a whole page in a copy paste ready format.

Update: you can now download the source as a zip file.

Update: Fixed the problem that not all generated passwords contained at least one character from each selected set. See the post announcing the update for details. Also, the new download location is my SVN repo: js_password_generator.html.

• digg.com – I’ve tried to register with them a couple of times, but was deterred by the following message: Sorry – only the characters a-z, A-Z and 0-9 are allowed in passwords. This makes me think that they store their passwords in cleartext in the database or something, because I see no other reason for this arbitrary restriction.
• blogger.com – Yes, the very service I’m using now. When I’ve registered yesterday I used the usual password generation algorithm an generated a long password with special symbols. Everything went fine, until the next day (today) when I tried to login. So I used the password reminder feature and learnt that the maximum password length was 20 (I used a password longer than that). This again leads me to believe that my passwords are stored in a database field in the cleartext (which probably has a size of 20 characters).

What I would like to ask the web developers:

• Only store the hashes, or better yet the salted hashes of my password
• Allow me to choose an arbitrary password with arbitrary characters (or if you want to limit for practical reasons use sensible limits like 255 ASCII – the original 7 bit ASCII – characters). If you store hashes the real length of the passwords has no effect on the data you have to store (it will be the same every time).
• If you have a limit, specify this and use the correct HTML attributes to signal this to the browser (like maxlength for the input elements)
• Update: As a commenter pointed out, you should transmit the password through HTTPS / SSL. For this it is enough if the target of the form is encrypted, the page the form resides on musn’t be encrypted and you are 100% secure (from a packet sniffing point of view), still it probably gives a good feel to users if the main page is also served over HTTPS (and probably it’s not that big a performance hit, especially with persistent connections. However remember that no encryption will protect you from spyware which installs itself directly into your browser (as a BHO for example).

Update: Please note that I don’t know whether they store my password as cleartext, as hash or salted hash. There might well be other (historical, security) reasons for the problems I’ve mentioned. I’ve personally used the password reminder feature of Blogger, and they’ve sent me a link using which I’ve could change my password – so I have no evidence regarding the method they use to store passwords, and I’ve never used this feature on digg. But my point was that they are limiting my security (or improving it, if you consider impossibility to log in an improvement :-)) by a choice which has no well founded reason.

Update #2: Blogger is now offering the posibility to log in with your google account (just go to beta.blogger.com) which is not subject to the restrictions mentioned above.

Please…