Question

I need a valid way to get both a random and unique string, with either a zero (or negligible) chance of a duplicate.

I need characters in the [0-9A-z] range.

This is what I have so far:

substr(sha1(mt_rand().uniqid()),0,22);  

Answer 1

Recent changes to PHP

Since I know this is actually talking about bcrypt and password salting now I can really just point people reading this to functions they should be using instead of manually rolling their own salt system.

Use password_hash($input, PASSWORD_DEFAULT); to generate a hash suitable to insert into a database. This will fetch the salt for you.

Insertion:

$hash = password_hash($_POST["password"], PASSWORD_DEFAULT, ["cost" => 16]);
DB::table("users")->insert(["username" => $user, "password" => $hash]);
// or whatever database method you use to insert data

Verification:

$hash = DB::table("users")->fetchByName($username)->select("password");
$input = $_POST["password"];

$verified = password_verify($input, $hash); // true if the password matches

In versions before PHP 5.5, use https://github.com/ircmaxell/password_compat as a drop-in¹

---

When randomly generating a salt, the odds of a collision are

1 / [number of possible letters/numbers] ** [length]

Which for a 22-character string are impossibly low (well, not impossibly, but negligibly)

1 / (22 ** 60) = 1 / (3.51043 x 10**80)

See? tiny.

---

Mathematical Fallacy

If you need a truly random string (note: these strings are just a line of numbers mapped to letters), then you’re a little out of luck.
What you’re looking for is a CSPRNG (Cryptographically Secure Pseudo-Random Number Generator). No need for uniqueness.

As @Guarav pointed out in his answer, you can use a timestamp as your seed and then hash it. This is called a UUID (Unique Universal Identifier, if it’s a 128bit timestamp) is predictable, and can be bad for a number of reasons:

1. The accuracy to which you take this timestamp becomes the deciding factor of how predictable this salt is.
2. If you take the time in seconds as an integer and hash it, then you end up with very defined and easily guessed salts

Nevertheless, with enough accuracy, you can still use a timestamp as a unique salt. Not random (unless you use it as a random seed and base convert it to base10, which is still a bad idea). Consider this if you can count time in something under nanoseconds and fancy using it as a unique ID. PHP cannot feasibly process fast enough to give two colliding sub-nanosecond IDs¹ (but that doesn’t mean you shouldn’t verify!)

---

^{1: It works with composer!}