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?

[quote author=Andy link=topic=17588.msg179112#msg179112 date=1217373010]
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?
[/quote]

Randomize?

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.

Perhaps you should check out advapi32's CryptGenRandom api.

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).

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

[quote author=Andy link=topic=17588.msg179121#msg179121 date=1217389407]
App.TaskID as the seed worked fine, as I said in my second post.
[/quote]

You never mentioned if it worked or not, smartass.

Why would it not work?

[quote author=brew link=topic=17588.msg179116#msg179116 date=1217378044]
Perhaps you should check out advapi32's CryptGenRandom api.
[/quote]

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:

[quote]
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.
[/quote]

[quote author=Andy link=topic=17588.msg179124#msg179124 date=1217394214]
Why would it not work?
[/quote]
If it's for anything security-related, then using a predictable value is a bad idea, as an attacker could potentially guess it.

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.

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

[quote author=iago link=topic=17588.msg179134#msg179134 date=1217448233]
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.
[/quote]
Which OS are you talking about?  Windows (at least Vista, I don't remember for XP) has per-user temporary file paths.

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.

[quote author=MyndFyre[vL] link=topic=17588.msg179135#msg179135 date=1217456259]
[quote author=iago link=topic=17588.msg179134#msg179134 date=1217448233]
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.
[/quote]
Which OS are you talking about?  Windows (at least Vista, I don't remember for XP) has per-user temporary file paths.
[/quote]
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. :)

[quote author=Andy link=topic=17588.msg179136#msg179136 date=1217457719]
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.
[/quote]
Nice, at the cost of requring administrator permissions to update!

[quote author=iago link=topic=17588.msg179137#msg179137 date=1217459577]
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. :)
[/quote]
Oh come on, we already knew the answer would be "Microsoft Windows XP, Visual Basic 6" :P

Brew, stuff it.
Iago, I'm dealing with the system I'm on for a program that can only run on the system I'm on. When I'm writing programs independent of the OS, I'll write them so they work for any OS. Riding a bicycle doesn't require a rear-view mirror.

Defensive programming should be a habit.

[quote author=iago link=topic=17588.msg179137#msg179137 date=1217459577]
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.
[/quote]
Why shouldn't you write to a system-provided temp directory just because other OSes use an inherently insecure method for storing temporary files? :P

What that really means is, if you want you can create a level of indirection such as, CreateTemporaryFile() that calls the appropriate OS-specific services for doing so.  I don't think it's reasonable to expect there to always be a global, portable API call for generating temporary files; however, Windows provides an easy set of API calls in order to retrieve this information: GetTempPath and GetTempFileName.  Note that GetTempPath uses the TMP and TEMP environment variables; while they can be modified, it requires an administrator to do so.  I don't know XP's default settings (but I know the behavior is to user-scope temp files), but Vista defaults both to %USERPROFILE%\AppData\Local\Temp, which ends up being the same result (user-scoped files).

I certainly don't advocate writing to the system folder in any scenario except installing a device driver, and even that's not necessary.

But let's not be coy.  It's not "un-defensive" to create temporary files in the Windows temporary file path.