Extending uniqid() or not?

string safe_uniqid([ing $length=64])

It generate ID using good RNG such as /dev/urandom, /dev/arandom for
UNIXes, openssl RNG for Windows when they are available. It does not use
hash function, but simply convert RNG binary data into text. The same
algorithm that is used for session ID may be used. (Use
hash_bits_per_character=5, since it only contains alphanumeric chars)
Since
it does not use hash, it's fast.

Any comments? Any good names?

The documentation for uniqid() is pretty clear about the fact that it's
not cryptographically secure and recomends openssl_random_pseudo_bytes()
as a replacement. Shouldn't we just try to come up with sane default
values for its $length parameter instead of adding yet another new
function?

I added the warning to the doc recently.

As far as I remember there was always a note about the non secure
usage uniqid. That's not something new, or am I mistaken?

I see codes that uses uniqid() as a source of safe unique id generation
using
hash functions which is not secure in fact.

Right, I see many insecure codes out there, even things like
unfiltered input usage. It does mean we can enable default filter per
default, f.e.

We are better to provide easy to use safe unique ID generation function to
prevent this kind of usage even if user could do in user land. Writing a
portable one is not simple enough.

We have one, http://de2.php.net/manual/en/function.openssl-random-pseudo-bytes.php.
It depends on openssl, but it is safe for the cases defined in your
other thread about session. On windows it is even always crypto safe.

string safe_uniqid([ing $length=64])

Besides the question about the need to add another function, I would
not use the word "safe" in any function name :)

P.S. Is anyone working UUID? PostgreSQL is using OSSP's UUID lib, it's
good

for PHP.
http://www.postgresql.org/docs/9.2/interactive/uuid-ossp.html

There's http://pecl.php.net/package/uuid.

It uses ext2 UUID. Isn' it only available for linux, is it?
It' a LGPL license also. It's not preferred license for core...

As long as it is not bundled, there is no big deal. And it should not
be lgpl v3, this license is a mess :)

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

On Sun, Feb 2, 2014 at 4:35 PM, Martin Jansen martin@divbyzero.net
wrote:

string safe_uniqid([ing $length=64])

It generate ID using good RNG such as /dev/urandom, /dev/arandom for
UNIXes, openssl RNG for Windows when they are available. It does not
use
hash function, but simply convert RNG binary data into text. The same
algorithm that is used for session ID may be used. (Use
hash_bits_per_character=5, since it only contains alphanumeric chars)
Since
it does not use hash, it's fast.

Any comments? Any good names?

The documentation for uniqid() is pretty clear about the fact that it's
not cryptographically secure and recomends openssl_random_pseudo_bytes()
as a replacement. Shouldn't we just try to come up with sane default
values for its $length parameter instead of adding yet another new
function?

I added the warning to the doc recently.

I see codes that uses uniqid() as a source of safe unique id generation
using
hash functions which is not secure in fact.

We are better to provide easy to use safe unique ID generation function to
prevent this kind of usage even if user could do in user land. Writing a
portable one is not simple enough.

string safe_uniqid([ing $length=64])

Sorry, there is typo and option should be descriptive. It should be

string safe_uniqid([int $length_of_returned_unique_id_string=64');

This function is totally different from current uniqid().
I don't like the name. I hope some one think of good name for it.

P.S. Is anyone working UUID? PostgreSQL is using OSSP's UUID lib, it's
good

for PHP.
http://www.postgresql.org/docs/9.2/interactive/uuid-ossp.html

There's http://pecl.php.net/package/uuid.

It uses ext2 UUID. Isn' it only available for linux, is it?
It' a LGPL license also. It's not preferred license for core...

I think it would be good enough to have only uuid v4:

function uuidv4()
{
$data = openssl_random_pseudo_bytes(16); // or whatever

$data[6] = chr(ord($data[6]) & 0x0f | 0x40); // set version to 0010
$data[8] = chr(ord($data[8]) & 0x3f | 0x80); // set bits 6-7 to 10

return vsprintf('%s%s-%s-%s-%s-%s%s%s', str_split(bin2hex($data), 4));

}

It's really just a representation of random data, whereby 6 bits are used
for the actual format.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--

Tjerk

Hello!

My personal view is that we need to start to beef up the default PHP
security, and a lot. Kind'a what has been done with the password API, also
needs to be done with a lot of stuff to make it's usage much easier and
much more secure by default.

And although I get the general feeling that PHP 5.6 has low probability of
getting such changes as this, PHP 6 by all indications is around the corner
and stuff like this has to go into it.

My 0.02$

Arvids.

Hi all,

What's wrong with mcrypt_create_iv() which exists specifically for the

purpose of generating secure random string?

User may use it. IV should be random bytes and it can be used as
secure source for hash. I does almost the same thing that I would
like to do. Issues are

• it does not auto detect RNG and use /dev/random by default
• it does not support /dev/arandom
• it uses php_rand() to create random bytes if source option is not
  RANDOM or URANDOM
• it is not an available function by default...

1st issue is not a issue actually. I think this is good that it uses
/dev/random by default
even if it may block script. As a crypt module, it should use most secure
source by default. We may improve mcrypt_create_iv() a little by raising
E_NOTICE
error when user set source other than RANDOM or URANDOM, and add ARANDOM
as a source.

Even though mcrypt_create_iv() good enough for it's original purpose, it's
not good as
a general (fool proof) method for generating random bytes as it can block
script execution.

I'm about to write patch improve mcrypt_create_iv(), but there is problem

IV source is defined as enum and user has to specify it as number

typedef enum {
RANDOM = 0,
URANDOM,
RAND
} iv_source;

To maintain compatibility, it would be

typedef enum {
RANDOM = 0,
URANDOM,
RAND,
ARANDOM
} iv_source;

Which seems a little odd to me. Anyway, possible patch would be something
like

diff --git a/ext/mcrypt/mcrypt.c b/ext/mcrypt/mcrypt.c
index 89ad83f..98b1848 100644
--- a/ext/mcrypt/mcrypt.c
+++ b/ext/mcrypt/mcrypt.c
@@ -539,7 +539,8 @@ PHP_MINFO_FUNCTION(mcrypt) /* {{{ */
typedef enum {
RANDOM = 0,
URANDOM,

• RAND

• RAND,
• ARANDOM
  } iv_source;

/* {{{ proto resource mcrypt_module_open(string cipher, string
cipher_directory, string mode, string mode_directory)
@@ -1387,8 +1388,23 @@ PHP_FUNCTION(mcrypt_create_iv)
}

iv = ecalloc(size + 1, 1);

• if (source == RANDOM || source == URANDOM) {

• switch(source) {
• case RAND:
• source = NULL;
• break;
• case URANDOM:
• source = "/dev/urandom";
• break;
• case ARANDOM:
• source = "/dev/arandom";
• break;
• case RANDOM:
• default:
• source = "/dev/random";
• }
• if (source) {
  #if PHP_WIN32
  /* random/urandom equivalent on Windows */
  BYTE *iv_b = (BYTE *) iv;
  @@ -1402,7 +1418,7 @@ PHP_FUNCTION(mcrypt_create_iv)
  int fd;
  size_t read_bytes = 0;

• fd = open(source == RANDOM ? "/dev/random" : "/dev/urandom", O_RDONLY);

• fd = open(source, O_RDONLY);
  if (fd < 0) {
  efree(iv);
  php_error_docref(NULL TSRMLS_CC, E_WARNING, "Cannot open source device");
  @@ -1428,6 +1444,7 @@ PHP_FUNCTION(mcrypt_create_iv)
  while (size) {
  iv[--size] = (char) (255.0 * php_rand(TSRMLS_C) / RAND_MAX);
  }
• php_error_docref(NULL TSRMLS_CC, E_NOTICE, "RAND is not safe");
  }
  RETURN_STRINGL(iv, n, 0);
  }

--
Yasuo Ohgaki
yohgaki@ohgaki.net

User may use it. IV should be random bytes and it can be used as
secure source for hash. I does almost the same thing that I would
like to do. Issues are

• it does not auto detect RNG and use /dev/random by default
• it does not support /dev/arandom
• it uses php_rand() to create random bytes if source option is not
  RANDOM
  or URANDOM
• it is not an available function by default...

1st issue is not a issue actually. I think this is good that it uses
/dev/random by default
even if it may block script. As a crypt module, it should use most secure
source by default. We may improve mcrypt_create_iv() a little by raising
E_NOTICE
error when user set source other than RANDOM or URANDOM, and add ARANDOM
as a source.

Even though mcrypt_create_iv() good enough for it's original purpose, it's
not good as
a general (fool proof) method for generating random bytes as it can block
script execution.

It is exactly because of of its blocking nature when the entropy source is
not sufficient that it is secure. This is the root difference between
urandom and random (or the likes).

My question is if we should extend uniqid() or add new function that
actually
generates safe ID string. We may add more description to uniqid() page,
mcrypt and

However we really do not crypto safe random bytes for this purpose. urandom
and similar are enough for session hash data or unique id. Non crypto safe
RNGs are not necessary unsafe, only not safe enough for cryptography
related operations, unique IDs is not a cryptography related operation.

Do you prefer documentation rather than extending uniqid() or new
function?

I think better documentation is a good solution.

Cheers,

Pierre

Hi!

• it does not auto detect RNG and use /dev/random by default
• it does not support /dev/arandom
• it uses php_rand() to create random bytes if source option is not
  RANDOM or URANDOM
• it is not an available function by default...

It's available if you include the extension, which you should if you
need security. And any support options can be added. Creating entirely
new function because existing function does exactly the same but doesn't
support one option or one specific setting for one use case doesn't
sound right to me.

Even though mcrypt_create_iv() good enough for it's original purpose,
it's not good as
a general (fool proof) method for generating random bytes as it can
block script execution.

If you use strict randomness function. If you use URANDOM, it would
never do it. All depends on your requirements.

My question is if we should extend uniqid() or add new function that
actually
generates safe ID string. We may add more description to uniqid() page,

How mcrypt_create_iv is not safe? It generates a random string, you need
a random string, what's unsafe in it?

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227