Diferencia entre java.útil.Random y java.seguridad.SecureRandom

Un random tiene solo 48 bits donde as SecureRandom puede tener hasta 128 bits. Por lo tanto, las posibilidades de repetir en securerandom son muy pequeñas.

Aleatorio utiliza el system clock como la semilla/o para generar la semilla. Por lo tanto, pueden reproducirse fácilmente si el atacante conoce el momento en el que se generó la semilla. Pero SecureRandom toma Random Data de su os (pueden ser intervalos entre pulsaciones de teclas, etc.-la mayoría de los sistemas operativos recopilan estos datos y los almacenan en archivos - /dev/random and /dev/urandom in case of linux/solaris) y los usa como semilla.
Así que si el tamaño pequeño del token está bien(en caso de Aleatorio), puede continuar usando su código sin ningún cambio, ya que está utilizando SecureRandom para generar la semilla. Pero si desea tokens más grandes (que no pueden estar sujetos a brute force attacks) ir con SecureRandom -
En caso de azar solo 2^48 se requieren intentos, con cpu avanzadas de hoy es posible romper en tiempo práctico. Pero para securerandom 2^128 se requerirán intentos, que tomarán años y años para romper el equilibrio con las máquinas avanzadas de hoy.

Vea este enlace para más detalles.
EDITAR
Después de leer los enlaces proporcionados por @emboss, está claro que la semilla, por aleatoria que sea tal vez, no se debe usar con java.útil.Aleatorio. Es muy fácil calcular la semilla observando la salida.

Vaya a SecureRandom - Use PRNG nativo (como se indica en el enlace anterior) porque toma valores aleatorios del archivo /dev/random para cada llamada a nextBytes(). Este forma en que un atacante que observa la salida no podrá distinguir nada a menos que esté controlando el contenido del archivo /dev/random (lo cual es muy poco probable)
El algoritmo sha1 prng calcula la semilla solo una vez y si su VM se está ejecutando durante meses usando la misma semilla, podría ser descifrada por un atacante que esté observando pasivamente la salida.

NOTA - Si usted está llamando a la nextBytes() más rápido que su sistema operativo es capaz de escribir bytes aleatorios (entropía) en la /dev/random, usted podría tener problemas al usar PRNG NATIVO. En ese caso use una instancia PRNG SHA1 de SecureRandom y cada pocos minutos(o algún intervalo), seed esta instancia con el valor de nextBytes() de una instancia PRNG NATIVA de SecureRandom. Ejecutar estos dos en paralelo asegurará que se siembra regularmente con valores aleatorios verdaderos, al tiempo que no agota la entropía obtenida por el Sistema Operativo.

Si se ejecuta dos veces java.util.Random.nextLong() con la misma semilla, producirá el mismo número. Por razones de seguridad que desea seguir con java.security.SecureRandom porque es mucho menos predecible.

Las 2 Clases son similares, creo que solo necesita cambiar Random a SecureRandom con una herramienta de refactorización y la mayor parte de su código existente funcionará.

Si cambiar su código existente es una tarea asequible, le sugiero que use la clase SecureRandom como se sugiere en Javadoc.

Incluso si encuentra que la implementación de la clase aleatoria usa la clase SecureRandom internamente. no debe dar por sentado que:

1. Otras implementaciones de VM hacen lo mismo.
2. La implementación de la clase Random en futuras versiones del JDK todavía usa la clase SecureRandom

Así que es una mejor opción seguir el sugerencia de documentación e ir directamente con SecureRandom.

La semilla no tiene sentido. Un buen generador aleatorio difiere en el primenumber elegido. Cada generador aleatorio comienza a partir de un número e itera a través de un 'anillo'. Lo que significa que vienes de un número al siguiente, con el viejo valor interno. Pero después de un tiempo llegas al principio de nuevo y empiezas todo de nuevo. Así que corres ciclos. (el valor devuelto por un generador aleatorio no es el valor interno)

Si usa un número primo para crear un anillo, todos los números en ese anillo obtienen elegido, antes de completar un ciclo completo a través de todos los números posibles. Si tomas números no primos, no todos los números son elegidos y obtienes ciclos más cortos.

Los números primos más altos significan ciclos más largos, antes de volver al primer elemento de nuevo. Por lo tanto, el generador aleatorio seguro solo tiene un ciclo más largo, antes de llegar al principio de nuevo, es por eso que es más seguro. No se puede predecir la generación de números tan fácil como con ciclos más cortos.

Con otras palabras: Tienes que reemplazar todo.

La implementación de referencia actual de java.util.Random.nextLong() hace dos llamadas al método next(int) que directamente expone 32 bits de la semilla actual:

protected int next(int bits) {
    long nextseed;
    // calculate next seed: ...
    // and store it in the private "seed" field.
    return (int)(nextseed >>> (48 - bits));
}

public long nextLong() {
    // it's okay that the bottom word remains signed.
    return ((long)(next(32)) << 32) + next(32);
}

Los 32 bits superiores del resultado de nextLong() son los bits de la semilla en el momento. Dado que el ancho de la semilla es de 48 bits (dice el javadoc), basta* con iterar sobre los 16 bits restantes (eso es solo 65.536 intentos) para determinar la semilla que produjo el segundo 32 bits.

Una vez que se conoce la semilla, todos los siguientes tokens pueden fácil de calcular.

Usando la salida de nextLong() directamente, en parte el secreto del PNG hasta el punto de que todo el secreto se puede calcular con muy poco esfuerzo. Peligroso!

* Se necesita algún esfuerzo si el segundo bit de 32 es negativo, pero uno puede averiguarlo.

Trataré de usar palabras muy básicas para que puedas entender fácilmente la diferencia entre Random y SecureRandom y la importancia de la Clase SecureRandom.

¿Alguna vez te has preguntado cómo se genera OTP(one time password)? Para generar una OTP también usamos la clase Random y SecureRandom. Ahora para hacer su OTP fuerte, SecureRandom es mejor porque tomó 2^128 intento, para romper el OTP que es casi imposible por la máquina actual, pero si se utiliza Clase aleatoria entonces su OTP puede ser agrietado por alguien que puede dañar sus datos, ya que tomó solo 2^48 tratar, para agrietarse.