A better random

[Barabajagal]

How can I generate a random value that's different every time the code is run, even if two instances of the application are run at the exact same time?

[l2k-Shadow]

How can I generate a random value that's different every time the code is run, even if two instances of the application are run at the exact same time?

Randomize?

[Barabajagal]

Randomize by default uses the gettickcount value as the seed value, which if run twice at the same time will return the same seed. I've set the seed value to the App.TaskID, and that should do it, I hope.

[brew]

Perhaps you should check out advapi32's CryptGenRandom api.

[iago]

You need a different source of entropy. Not sure how to do it on Windows, but the advapi32 functions might work (see brew's post).

[Barabajagal]

App.TaskID as the seed worked fine, as I said in my second post.

[bulletproof tiger]

App.TaskID as the seed worked fine, as I said in my second post.

You never mentioned if it worked or not, smartass.

[Barabajagal]

Why would it not work?

[MyndFyre]

Perhaps you should check out advapi32's CryptGenRandom api.

The nice thing about the CryptGenRandom API (and the .NET equivalent) is that it accumulates system-wide; the kernel handles synchronization and ensures that two processes, even calling with exactly the same data and at exactly the same time, are going to be processed in serial, and so hardware conditions provided for in the documentation serve to enhance its security:

With Microsoft CSPs, CryptGenRandom uses the same random number generator used by other security components. This allows numerous processes to contribute to a system-wide seed. CryptoAPI stores an intermediate random seed with every user. To form the seed for the random number generator, a calling application supplies bits it might have—for instance, mouse or keyboard timing input—that are then added to both the stored seed and various system data and user data such as the process ID and thread ID, the system clock, the system time, the system counter, memory status, free disk clusters, the hashed user environment block. This result is SHA-1 hashed, and the output is used to seed an RC4 stream, which is then used as the random stream and used to update the stored seed. If an application has access to a good random source, it can fill the pbBuffer buffer with some random data before calling CryptGenRandom. The CSP then uses this data to further randomize its internal seed. It is acceptable to omit the step of initializing the pbBuffer buffer before calling CryptGenRandom.

[iago]

Why would it not work?

If it's for anything security-related, then using a predictable value is a bad idea, as an attacker could potentially guess it.

[Barabajagal]

It's to generate a folder name in the temporary files directory, which is removed on program termination and stores skin data (images and text) mostly.

[iago]

On a multi-user machine, that can cause a security problem. Seriously.

It's a common mistake to create temporary files in a globally writable directory with predictable filenames. The program could be tricked by a malicious user into over-writing system files under certain conditions.

There should be a built-in function to securely generate temporary files/folders, you should use that.

I don't know which language you're using, but this guide might help you out:
https://www.securecoding.cert.org/confluence/display/seccode/VOID+FI039-C.+Create+temporary+files+securely

[MyndFyre]

On a multi-user machine, that can cause a security problem. Seriously.

It's a common mistake to create temporary files in a globally writable directory with predictable filenames. The program could be tricked by a malicious user into over-writing system files under certain conditions.

There should be a built-in function to securely generate temporary files/folders, you should use that.

Which OS are you talking about?  Windows (at least Vista, I don't remember for XP) has per-user temporary file paths.

[Barabajagal]

As MF says, the temp dir tends to be something along the lines of C:\Documents and Settings\[USERNAME]\Local Settings\Temp\ (in winxp), and my bot (written in VB6, as the location of this topic suggests) writes to a subfolder called RCB within that temp folder.

My program already overwrites system files, seeing as it updates files stored in the System32 folder (or SysWOW64 if you're on an x64 OS), since it seemed like a better place to store runtimes than the application directory in order to keep things simple for users.

[iago]

On a multi-user machine, that can cause a security problem. Seriously.

It's a common mistake to create temporary files in a globally writable directory with predictable filenames. The program could be tricked by a malicious user into over-writing system files under certain conditions.

There should be a built-in function to securely generate temporary files/folders, you should use that.

Which OS are you talking about?  Windows (at least Vista, I don't remember for XP) has per-user temporary file paths.

I think that every OS except for windows uses a global temp directory (Linux, BSD, and Mac all use global files, as far as I know).

It's probably ok if per-user temp files are used, but I think it's important to get into good habits no matter which OS you're on.

And for what it's worth, he didn't specify an OS or a language or anything else in his initial post, so I gave a generic answer.