¿Cómo aseguro un valor nonce dentro de la aplicación cuyo código fuente es público?

Soy uno de los mantenedores principales de Nylas N1. Creo que la otra respuesta es un buen consejo general, pero aquí hay algunos consejos más específicos para N1:

• Si desea asegurar un proceso o algoritmo, puede escribirlo en un módulo de nodo nativo que se distribuye en forma binaria. Actualmente no hacemos esto, pero muchas otras aplicaciones basadas en JavaScript sí (el DRM de Spotify se encuentra en una biblioteca de C ++ que distribuyen junto con JS).

• Si desea autenticar al cliente con un servicio, use OAuth de 3 patas. Con OAuth de 3 patas, distribuye el Application ID pero no el Application Secret en el cliente. Cuando el usuario inicia sesión, se devuelve un Code y usted entrega ese Code a su propio servidor (el tercer tramo), donde se utiliza el Secreto de la aplicación para intercambiar el código por un token , que se envía de vuelta. al cliente. Este proceso es una tarea difícil de implementar, pero garantiza que los únicos tokens confidenciales que tiene el cliente son las cuentas que el usuario autenticó.

• Si desea almacenar tokens, claves de API de usuario, etc. del lado del cliente, le sugerimos que utilice node-keytar . Ya está disponible en N1 a través de require('keytar') . Proporciona una API simple para almacenar secretos en el llavero del usuario en Mac, Windows y Linux. Actualmente lo usamos para almacenar tokens N1 API.

Espero que ayude! Siéntase libre de comunicarse conmigo o con otros ingenieros de Nylas en nuestro canal de la comunidad en enlace

En general, no puede confiar en CUALQUIER COSA del cliente; este es el problema que enlace está destinado a resolver, pero Ese es un largo camino para bajar. Lo mejor que puede hacer es autenticar al usuario y asegurarse de que todas las acciones de ese usuario estén autorizadas, independientemente de que provengan de una aplicación cliente real o de alguien que juegue con su api, a través de MITM o mediante acceso directo.

Como @Bakuriu señala anteriormente, los valores no aleatorios son valores aleatorios, se usan una vez, son diferentes todo el tiempo; se usan para prevenir ataques de repetición y como tokens en los esquemas de prevención CSRF, por ejemplo. Lo que está pensando es, quizás, una clave API, un valor utilizado para autenticar a un usuario (donde el usuario podría ser un programa). Como dice, no puede incorporarlo a la aplicación, ya que el usuario puede acceder a ella mediante el desmontaje, la inspección del código fuente o la inspección del tráfico de la red.

Por lo tanto, vaya por la ruta de no confiar en el cliente. Eso significa que cada usuario debe estar autenticado, independientemente del cliente que use. Luego, verifica que ese usuario tenga permiso para realizar la acción que desea. Puede emitir claves de api para cada usuario.

Un posible esquema: pídales que verifiquen quiénes son al iniciar sesión en su sitio web y generar una clave para ellos que puedan proporcionar a la aplicación: la aplicación puede guardarla en el llavero del usuario si desea que sea conveniente. Cuando intenten realizar una acción, verifique la clave api en su base de datos. Mientras todo esto se haga a través de canales seguros, es razonable y es utilizado por muchos servicios.

Otro: haga que el usuario se autentique en su servicio (potencialmente a través del inicio de sesión con Facebook o lo que sea; auth / openid son buenos). Luego verifique al usuario directamente en cada solicitud.

Ambos tienen la ventaja de que son fáciles de revocar y de que puedes limitar al usuario a lo que tienen permitido hacer, independientemente de cómo realicen la solicitud.

TODAS las verificaciones de autorización y la verificación de autenticación deben realizarse en el lado del servidor, siempre. El cliente se encuentra en territorio enemigo y nunca se puede confiar en él (excepto la fealdad del TPM).