We Keep Coding

Producing the same signature with WebAuthn

I just started playing around with WebAuthn on localhost. I was given to understand that the signature value found in credentials.response.signature was signing credentials.response.clientDataJSON. However, for the same inputs / challenge for navigator.credentials.get I seem to be getting a different signature. My best guess is there is a timestamp or counter going somewhere into the value that is signed?
I can't seem to decode the signature or authenticatorData, which would really help me to visualize what's going on inside. I'm able to decode clientDataJSON as follows, anyone have sample code with which I code decode the other two aforementioned params?
String.fromCharCode.apply(null, new Uint8Array(credentials.response.clientDataJSON))
I also found when decoding clientDataJSON I get the occasional extra field in Chrome, which is a little annoying for my use case.
My goal is to get the user to produce the same signature or hash each time when authenticating the same PublicKeyCredential. Is there a way to do this? or are there other methods within the scrope of WebAuthn or outside of its scope to benefit from the biometric auth with which I can produce identical signatures or hashes from the same inputs?
Please forgive any misconceptions I might have about WebAuthn, I'm quite new to this amazing tech. I completely understand that this is not the original intended use of WebAuthn so a janky workaround may be needed.

My goal is to get the user to produce the same signature or hash each time when authenticating the same PublicKeyCredential.
This is actually a really bad idea. The whole purpose of signing a message with a random challenge is to avoid replay attacks. Otherwise, if an attacker somehow intercepts an authentication message, that message could simply be reused to impersonate the user.
I was given to understand that the signature value found in credentials.response.signature was signing credentials.response.clientDataJSON
That is not accurate. The signature signs authenticatorData + SHA256(clientDataJSON).
Both are variable. The authenticatorData contains a "counter" increasing each time the credential key was used to authenticate and clientDataJSON should (or must to be secure) contain a randomly server side generated challenge.
I can't seem to decode the signature or authenticatorData, which would really help me to visualize what's going on inside. I'm able to decode clientDataJSON as follows, anyone have sample code with which I code decode the other two aforementioned params?
The signature cannot be "decoded", it can only be "verified" given the adequate public key. For the other paramters authenticatorData and clientDataJSON , check out the following link at the bottom, it will decode them.
https://webauthn.passwordless.id/demos/playground.html
I also found when decoding clientDataJSON I get the occasional extra field in Chrome, which is a little annoying for my use case.
I'm not sure, I believe this is related to localhost testing.

If you want a small, fixed bit of data associated with a credential then you may wish to investigate the credBlob or prf extensions. Not all authenticators will support them, however. Many more will support prf but support for that in Chromium won't appear for a few more months. So there's not a great answer here yet, but it may work better than trying to fix the signature.

So, first things first, in general it depends on the signature scheme used whether the same signature will be produced when you use the same data as input. Check this question https://crypto.stackexchange.com/questions/26974/ where they discuss about it.
Now, coming back to WebAuthn (assuming that you use a signature algorithm that for the the same input will generate the same signature) let's look how the signature is generated. Here is a small code from my virtual authenticator that is responsible for generating the WebAuthn signature:
let authData = this._concatUint8Arrays(
rp_id_hash,
flags,
sign_count, // The signature counter will always increase
this._getAAGUID(),
credential_id_length,
credential_id,
cose_key
);
// Attestation object
let attestation_object = {'fmt': 'none', 'attStmt': {}, 'authData': authData};
// ...
// Generate signature
let client_data_hash = new Uint8Array(await crypto.subtle.digest('SHA-256', client_data));
let signatureData = this._concatUint8Arrays(authData, client_data_hash);
let signature = await Algorithms.Sign(this.private_key, signatureData);
You will notice that the data to be signed include the authenticator's signature counter which should increase each time you use the authenticator. This helps detecting replay attacks or cloned authenticator attacks (more info here).
Thus, it is not feasible to generate the same signature.
If you want to look more into what is going on under the hood of WebAuthn you can have a look into my WebDevAuthn project and browser extension that allows you to inspect the WebAuthn requests and responses.

Am I hashing passwords correctly?

My current project is my first in Node.js (also using MongoDB, Mongoose, and Express, if it matters), and being easily distracted, I have fallen down the rabbit hole of crypto while deciding how to handle user authentication. (No other encryption is needed on this project).
Following the pattern on this page (pattern, not code - I am having problems with installing node.bcrypt but not with node-sodium) and also this page my process is
new user submits password over https
the schema generates a salt
schema hashes a concatenation of the password and salt
schema stores the salt and the password with the user information
Now I don't know if this my personal deficiency, but I am having trouble following the libsodium documentation. node-sodium does not provide any additional information for hashing (though it does have an example for encryption).
This is the code I want to use to generate the hash:
let buf = new Buffer(sodium.crypto_pwhash_STRBYTES);
sodium.randombytes_buf(buf, sodium.crypto_pwhash_STRBYTES);
let salt = buf.toString();
let preBuffer = "somePass" + salt;
let passwordBuf = Buffer.from(preBuffer);
let hash = sodium.crypto_pwhash_str(passwordBuf, sodium.crypto_pwhash_OPSLIMIT_INTERACTIVE, sodium.crypto_pwhash_MEMLIMIT_INTERACTIVE);
So the question is two parts. Is this a good process, and is the code appropriate?

I've used the scrypt-for-humans package in the past for exactly this reason.
https://github.com/joepie91/scrypt-for-humans
Scrypt is a very secure hashing library and this higher level wrapper makes it hard for you to mess anything up. It's also specifically designed for securely hashing passwords so thats a positive as well :)

At the moment the best password hashing algorithm is Argon 2. There is a module called secure-password written by Emil Bay. He talks more about cryptographically secure password hashing and best practices on this podcast. Here is a snippet of what he said about Argon 2.
Normally when you lay out a threat model, perfect security from a mathematical point of view is almost never practical. (In cryptography, can be referred to as perfect secrecy which means, even if you have an enormous computer the size of the universe, it doesn’t matter how big it is, you can never break the security, but that’s not really practical in the real world.) Instead you go for something called computational secrecy. Which means you can break this, but it will cost you too much money and take too much time.
The goal of these hash functions is to make it so expensive to brute force these algorithms that there would be no point in trying. In a threat model, you know that you are not going to get perfect security but can you make it so expensive for your adversary to attack you.
Argon 2 has two parameters that make it immune to large scale GPU attacks. You can control how much memory the function is allowed to use, and you can control how much computation time taken to make a hash. A CPU usually has a lot of memory but a few cores. A GPU has very little memory but thousands of cores. Argon 2 dials up a lot of memory that you can only do about 4 or 8 simultaneous Argon 2 hashes on a single GPU which makes it too expensive to try and crack. In secure-password, I’ve taken the values that Frank Denise who made sodium which it’s built on figured out. It’s within the bounds of an interactive service like a website can afford to create reasonable security without slowing down. To hash a password, you need about 16 or 32 Mb of memory and those parameters can be controlled in Argon 2.

Personally I've used crypto and I do exactly the same 4 steps you are doing right now (after checking a few conditions 7 chars pass, one symbol, one number... ). I'll share the code using crypto.
var salt =rand(160, 36);
var salted_pass = salt + password;
var token = crypto.randomBytes(64).toString('hex'); // I even generate a token for my users
var hashed_password = crypto.createHash('sha512').update(salted_pass).digest("hex");
EDIT: Warning this is not a completly safe method of doing it, as it may turn predictibly. Refer to comments below which explain why it is not a good method.

JavaScript Games and Security

Let's say I'm making an HTML5 game using JavaScript and the <canvas> The varaibles are stored in the DOM such as level, exp, current_map, and the like.
Obviously, they can be edited client-side using Firebug. What would I have to do to maximize security, so it would be really hard to edit (and cheat)?

Don't store the variables in the DOM if you wish a reasonable level of security. JavaScript, even if obfuscated, can easily be reverse engineered. That defeats any local encryption mechanisms.
Store key variables server-side and use https to maximize security. Even so, the client code (JavaScript) is quite vulnerable to hacking.

You can use Object.freeze or a polyfill or a framework which does the hiding for you.
Check out http://netjs.codeplex.com/
You could also optionally implement some type of signing system but nothing is really impenetrable. For instance objects locked with Object.freeze or Object.watch can still be manually modified in memory.
What are you really trying to accomplish in the end?
What you could do is send a representation of the matrix of the game or the game itself or a special hash or a combination of both and tally the score at the server... causing the user to not only have to modify the score but to correctly modify the state of the game.

Server-side game logic
You need to keep the sensitive data on the server and a local copy on the browser for display purposes only. Then for every action that changes these values the server should be the one responsible for verifying them. For example if the player needs to solve a puzzle you should never verify the solution client side, but take for example the hash value of the ordered pieces represented as a string and send it to the server to verify that the hash value is correct. Then increase the xp/level of the player and send the information back to the client.

Anything that is living in the client can be modified. That is because in MMORPG the character's data is living on the server, so players can't hack their characters using any memory tools, hex editor, etc (they actually "can", but because the server keep the correct version of the character's data is useless).
A good example was Diablo 2: you have actually two different characters: one for single player (and Network playing with other players where one was the server), and one for Battle.net. In the first case, people could "hack" the character's level and points just editing the memory on the fly or the character file with an hex editor. But that wasn't possible with the character you was using on Battle.net.
Another simple example could be a quiz where you have a limited time to answer. If you handle everything on client side, players could hack it and modify the elapsed time and always get the best score: so you need to store the timestamp on the server as well, and use that value as comparison when you get the answer.
To sum up, it doesn't matter if it's JavaScript, C++ or Assembly: the rule is always "Don't rely on client". If you need security for you game data, you have to use something where the clients have no access: the server.

Open Source remote / distributed / persistent JSON object library for Python serverside and Javascript clientside?

I'd like to be able to have Javascript code manipulate a persistent JSON object in the browser, and have it synchronise with the server, and other clients in real time.
I'm already using MVC separation.
I'd like to be able to do something like this:
function sendMessageToUser(username, message){
messageID = window.model.userMessages[username].messages.length;
window.model.userMessages[username].messages[messageID] = message;
window.requestModelSync();
}
in this example, window.model is a JSON object that is syncronised periodically or on demand, with errors upon collisions, so 'heavy' client code can handle such an event (it is not caught in the example, but if another user messaged the same user at the same time before syncs occurred, an error might be raised by the sync library).
The view code would be called upon a model change and would re-render the messages for the user - in real time.
Are there any libraries that do this already that are somewhat simple, and open-source?
Assuming it's not so secure, I'd like to add cookie based user authentication and key / value validation to it, assuming it doesn't exist already - while still using JSON, with no schema's or models required to start hacking.
I've seen Robert Sayre's sync.js which could be a key building block but I'd like to see something more fully formed, and preferably in use already. I.E: COMET, collision avoidance / resolution strategies, low bandwidth use etc already implemented.
If it doesn't exist I'd be happy to work on such a plugin with people skilled in Python and Javascript.
I've seen http://persistencejs.org/plugin/sync - it is not JSON, they end up defining their own model class.
I don't want to use something as complex as Apache Wave's API's either. Simplicity for prototyping is a key goal.

Firebase is a good candidate for solving your problem.
There isn't a native Python library, but there is a Python wrapper around the REST API
See:Firebase
Firebase home page

Server-side highscores for a Javascript-written game

I'm implementing a simple game in Javascript, and am interested in having an online highscores table for it, so that players can compete against one another. I've two concerns about this:
What is the simplest server-side program I need for this purpose? I don't need a full-fledged "web application", just something simple that gets POST requests with highscores, updates a database and sends back lists of scores. I'm familiar with Django. What are your suggestions?
How can I make the highscores table reasonably secure? I'm aware that making it bulletproof against competent and dedicated hackers is difficult, but I wouldn't want anyone with access to the Javascript sourcecode to be able to submit fictitious scores too simply. Any tools for this purpose?

It's going to be pretty hard to secure the high scores. I mean, it's not enough to ensure that it comes from your page, because if, say, the JavaScript function is submitHighScore(n) then they can always type javascript:submitHighScore(10000000) in the address bar on that page and have it work.
What comes to mind is perhaps some sort of hash function that generates specific codes that match certain levels in the game. When submitting the score it would also submit this hash, so users would have had to get to this level in order to get that equivalent score.
Another option would be for the game to pull in some kind of key that only works temporarily, so as you went along the key would change and then the score would be submitted to a central server intermittently.
Keep in mind that really determined individuals can always just track the data being sent to your data and decompile it.
You could go the Broderbund route and ask the player trivia questions which are validated server-side to ensure they really did pass the level they said they did...something like "What color was the monster in the previous level?"

To submit score securely, sign it (you'd also need to ensure that the score isn't faked before it's signed and sent, but that's another problem).
Hide a secret in JS code, and send highscore + hash(highscore + secret) to the server. The hash could be MD5/SHA1 — there are easy to find JS implementations.
Of course it won't stand anyone carefully analysing the JS code, but at least someone won't be able to submit fake highscore just by tampering with HTTP traffic.
On hiding stuff in JS:
You can't really hide it (it's ultimately futile like DRM), but you can try hard to obfuscate it and make debugging painful.
Don't put the secret as a literal in the source code - compute it at run time combining results of several functions, local and global-ish variables.
Minify all code, remove sourcemaps.
Add bits of code that don't do anything, but seem to be important, to make debugging more confusing.
Don't put anything in global scope, but do rely on shared mutable state by passing closures and arrays around.
Rely on Date and timers to cause race conditions to make your code produce wrong results if it's paused in the debugger (just don't make it too tight to allow it to run on slow machines).
If the game is deterministic (like a puzzle game), then users could submit highscore in form of a log of steps taken to win (user's input) that you'd replay on the server to calculate the score.
This would change attack from finding/emulating score-submitting function to witing AI or hacking the game itself to make it easier to play (but still within its basic rules).

1.) Any CGI script that can talk to a database and understand JSON, or other format of your choice, will do the work.
However, if you're familiar with Django, building your server on top of Django would be the most simple, in the sense of what you have to learn and how much application code you have to write. Seemingly simple CGI script can turn out rather complex if you write it from scratch.
I found django-piston to be a handy Django app to quickly write a REST-style API server. It supports JSON so it should be easy to interface with your JavaScript game.
2.) The most casual cracker will go for a replay attack and its variants: peek at the page source and execute a JavaScript function, intercept HTTP requests and resend it (should be easy with a Firefox add-on like Tamper Data).
To counteract the former, you can obfuscate the source code and HTTP body;
Minify the JavaScript code
Encode the message you send to the server with Base64 or other encoding algorithm
The latter can be prevented by requiring all update requests to include an one-time password ("session token" in the Wikipedia article) that was recently acquired from the server.

I am thinking about this myself. What seems to be the most reasonable solution to me is this:
1) Sessions, to disallow tampering with the scoretable outside the game.
2) Log every action in the game and send it to the score server. The server will then calculate if those actions actually give such score. If you also log the time spent playing the game, you can further minimize the chance of an attacker to bother himself enough to break your game. This will also enable you to make a replay script like Arcade servers with hi-score tables have and in case of a suspicious score, you can watch the replay and decide for yourself if the score is real. The cheater would have to use a clever bot to play your game - and unless you have a game for real prizes, noone will try that hard.
If the cheater won't even analyze your code, sessions will stop him. If he reads your code, he would quickly break anything similar to hashed scores, secrets, tokens and whatsoever. But if you make the game-logging script thorough enough, he will give up.

In answer to your question:
1.) This depends on your environment and coding preference. PHP, Python, ASP.NET are a few that come to mind. Sense you already know Python (from your profile) you can use a Python CGI script to do this or use one of the many frameworks for Python (Zope, Django, Pylons,...).
see: http://www.python.org/doc/essays/ppt/sd99east/index.htm
for info on Python CGI.
2.) A few tricks for security: (none or full-proof)
Hidden Text Box in HTML with encoded value that server checks to match a cookie to ensure high score comes from your page.
Server Script only accepts values from a specific domain

You could use a combination of one of the methods above, as well as simply requiring the user to be registered to be able to post high scores. Non registered users could view their current score compared to existing high scores, but in order to post your high score online, you must have already logged in with your registered account, or provide it when the app goes to update the score online.
A simple message along the lines of "Your high score is X, and ranks ### in the high score table. To post this score online, please register with us first".

The better I think, is to make the calculation of the score directly into the python files of your django app.
Instead of calculate it in the javascript file. You send the datas to compare with your data basis with a POST request, then you calculate the score and you store it in your data basis. Like this, you don't make circulate the score across the web to your servers. Which is completely safe because you are only doing local stuffs.