Is it possible for a Javascript client create a UUID that cannot be faked?
For example, suppose one of the solutions from Create GUID / UUID in JavaScript? were used to generate a UUID and send a create request with UUID to the server. Is it possible for the server to check that the UUID was indeed created by the Javascript function and not by some other function?
One idea is to use a checksum, but the UUID generation and checksum code would be visible to a "hacker". They could simply modify the Javascript function and then add the checksum.
So, are there any good solutions to this problem?
You shouldn't care about who created the UUID. The server should only check if the UUID sent by the client respects the UUID format and perhaps check if somehow the same UUID was used already (this depends on your needs).
That is unless your UUID value is used as a secret (e.g. an activation number). In this case, the value shouldn't be generated client-side and the server should keep track of the values it generated.
You can do some basic sanity checks like length or format, but what you are actually asking is "Given a number can I check that it was generated by a particular random number generator?". If the random number generator is truly random then the answer has to be "no", since if I can back-track from the answer to the function that easily then it's not very random.
Related
I need to keep a unique identifier for each client using my react app.
doing this will regenerate a random string (what I want) but does this on each refresh which is not what I want
const [id] = useState(Math.random().toString(36).substr(2, 8));
I've found uniqueId() form lodash but I'm afraid the id's won't be unique across multiple clients as it only give a unique Id and increment it at every call (1, 2, 3...)
const [id] = useState(_uniqueId());
Is there some kind of _uniqueId that generates a random string and also persist through page refresh?
I don't think there is a built-in or out-of-the-box solution that generates unique id in react that persist automatically. You have two problems to solve.
How to generate unique id. Which was already solved by using the uuid.
And how to persist it.
There are plenty of storage you can use depend on your need. Here's few of them where you can persist your data assuming you want it to be stored in client side.
LocalStorage
SessionStorage
Cookie
IndexedDB API
FileSystem
Again, it depends on your use case. So, carefully check them out which one fits on your requirement.
Another way to generate a temporary ID that would be the same for the same client, without storing it is to use browser fingerprinting.
For example, you can take user-agent, client timezone, and screen resolution, apply some hash function to them and call it an ID.
There are more advanced ways of fingerprinting that would result in less chance of two different users having the same ID, but it'll never be a 0% chance.
You also might want to use some libraries, such as https://github.com/fingerprintjs/fingerprintjs for this.
I am using Parse (www.parse.com) as backend in one of my project.
I would like to generate unique random (Promocode) by applying the current date and time every time in Java script. The random should be readable alphabets / numbers.
I know the the random generation process by searching in Google. But I am not sure whether this is unique always. So to check that, every time i have to contact the backend, whether any already existing random which matched to the current one. It is being a long process. Since I require this process to do at sign up process, I need a better solution for this.
Can anyone help on this?
What i could understand from your question is that you want a good hash function which ensures that the values are unique every time so you won't have to do the long processing of checking whether the value is unique or already exists.
First let me clear out something, hashing isn't doesn't necessarily mean 'unique' but they are supposed to be 'unique enough'. For the best hashing library in JS, you should check out crypto.js
They have different kinds of hashing functions available, take a look at this one:
<script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/sha256.js"></script>
<script>
var hash = CryptoJS.SHA256("Message");
alert(typeof hash); // object
alert(hash); // 2f77668a9dfbf8d5848b9eeb4a7145ca94c6ed9236e4a773f6dcafa5132b2f91
</script>
I mean look at the value generated by that hash function.. the possibility of having a duplicate of that value is extremely extremely slim. So, you can safely use that one or also dig out the library to use the one which you think is the best for you.
I'd like to use Firebase to make publicly-readable data whose location is difficult to guess. So, to give someone access to the data stored in "element [element ID = X]", I'd like to just send them "X", instead of sending them "X" along with a security token crafted to give them access to the element. Firebase's push() and childByAutoID seem like a natural fit: I can grant public read access to all individual elements, but deny public listing. My code will be blissfully free of token and random number generation. The automatically generated ID is supposed to be unique, and thus should be difficult to guess.
From looking at Firebase.js, it appears the first 8 characters of the automatically generated ID are based on the current timestamp, and the next 12 characters are randomly generated using Math.random(). I assume that the iOS framework does the same thing, and although I can't see the code, the library links to both SecRandomCopyBytes and arc4random.
For my purposes, this looks good enough, but has anyone seen guidance from Firebase on whether we can count on this behavior? I would hate to build code that assumes these names are relatively strong random strings and then have that assumption violated when I upgraded to a newer version of Firebase.
The purpose of the auto-generated IDs provided by Firebase is to allow the developer to create a chronologically ordered list in a distributed manner. It relies on Math.random and the timestamp to generate an ID unique to that client.
However, if you're going to use the auto IDs as security keys, it may not be the best idea depending on how secure you want your system to be. Math.random is not a cryptographically secure random number generator and since push() relies on it, the IDs generated by it aren't either.
The general concept of giving a user access to some data in Firebase if they know the key is a good one though. We have an example of using this type of security rule, but instead of using push IDs, we use a SHA-256 hash of the content itself (in this particular case, they are images). Hashing the content to generate the keys is more secure than relying on push() IDs.
I'm building a web app that sends a person an email every time the person is handed a document (a physical piece of paper). The email contains a link that allows the user to request for a document pick up. The link should contain the user's id and the document's id. Is there a safe way to generate this link? Is this a good practice or are there other ways to implement such a thing?
I was thinking of using a hashing algorithm on the link, is this a good approach?
I'm using expressjs for my server side.
Thanks
Use for example node-uuid to create a UUID and pass it on the link, then store on the database to which document the UUID is linked to.
This solves several problems:
an attacker cannot guess UUIDs
there is no information on the UUID that can be extracted
I don't think hashing would help in this case, as we just need a way to create a one time token that cannot be guessed.
Hashing, obviously, will not include the document and the user's ID. So it's a bit confusing whether you want secure obfuscation (in which case you would want to use a hash algorithm (salt it if you're paranoid) that then quickly checks whether there is a document with the same ID and generates a new one to avoid document-ID mismatch) or that user and document IDs be included (in which case creating a format that includes both and a brief, usually session-dependent, ID to prevent document-ID mismatch will be just perfect).
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.