Yep, I always work on the principal that a GUID may be duplicated so I add Ticks since the Epoch or something like that to my GUIDs because Ticks should only ever increase. The chances of getting the exact same ticks in milliseconds AND a duplicate GUID are not gunna happen! you're welcome :)

G'Day, Yes you are correct you cannot just generate a new random salt at each authentication. You ONLY generate the random salt when the password is created, and the sal is indeed stored somewhere, generally in the DB with the Hash. Now what you are saying is if the DB is compromised and the attacker gains your hash and your salt you suggest that they are pwned and can then use the salt to generate a hash table. Now you are correct that the salt can be used to generate a hash table however that is why simply salt + hashing is not good enough. You also need to implement key stretching. The point of key stretching as per PBKDF2, Bcrypt etc, is such that generating said hash table takes an INFEASIBLE amount of time. It does this by performing a hash function such as HMACSHA1 over x (supplied) number of times and XORing the result of each pass with the previous one. If each hash generation takes half a second, it would take 1 second to generate two hashes! Making hash table generation not a viable option. So basically it is fine for the attacker to gain your salt, hell give it to them if they ask for it even....you should always assume your salt is known anyway!!! So folks always remember salt + password -> Key Stretching Function -> hash output to store. I think the provided article does a better attempt at explaining than me but I hope I make sense anyhow :) Cheers, Ian

"And so back to square one..." - Neggative, Salt is not a secret value, it merely serves two purposes: Purpose a) By forcing the use of a salt, we need to generate a hash table for every available salt to get passwords that are using that salt, driving up the cost of hash table creation (as rather than one table for all passwords, need one table per salt) Purpose b) By using Salt we ensure that two passwords of the same value have different hash value due to the different salts....this stops things like finding all users with hash 1e0b2ffs7 blah mc blah and tying that hash to a specific password. i hope I make sense, but if you want a .NET API to do it properly than look no further than here: http://sourceforge.net/projects/pwdtknet/[^] :)

WiFi all the way!!! I currently have my old Billion cranking out 802.11g and I have no problems whatsoever. It is secured with WPA2-PSK and I download torrents at speeds around 1.5 MB/s some times. A good download server like microsoft download sees me download @ around 1.8 MB/s (My ADSL2+ is Syncing to the DSLAM @ ~19mbs)and so wireless g is more than enough as it is faster than my internet anyway....and LAN wise I do the odd media streaming and thats bout it so I'm fine with g and couldn't even be bothered upgrading to n. If for somereason you do live in a palace, you can get wifi range extenders (repeaters) to re-transmit your wifi into dead spot areas......cables are a thing of the past.....get with the times!!!!