No no, el ERE lo he vivido durante las prácticas

Un porrón de peña a la calle

pufff

Menos mal que me escapé a tiempo

Decian que Defensa y Transporte estaban bien de curro, el resto no tanto

No sé, en el proyecto que estaba yo si que hace falta gente

Porque el equipo es muy pequeñito y tienen un montón de trabajo

Y siempre están pidiendo prestada gente de otros proyectos, pero claro...

Ya veremos qué sale, al menos para hacer un poco de CV me dará

Buenos días gente

¿Es seguro utilizar el local storage para almacenar datos que vayamos a utilizar mucho? ¿Qué tan seguro es hacerlo?

Necesitas PERSISTIR esos datos??

Si no, lo más fácil es tenerlos directamente en memoria en una variable

No, los tengo persistidos en mongo

A ver la idea es por ejemplo guardarme el token del usuario y el rol, o algo así

Es mucho más rápido acceder a un objeto global que contenga los datos que necesitas, como si fuese una in-memory DB

lo que no sé es si esa información se puede ver comprometida

El localStorage es completamente visible para cualquiera con acceso al pc, ten eso en cuenta

Viene a ser más o menos igual de seguro que una cookie al final

Pero para almacenar tokens está bien

o sea, que si el pc es compartido por varios, un usuario podría ver los datos de otro

Depende de cómo lo tengan montado

Pero si pueden entrar con el usuario del otro, desde luego que si

que se suelen guardar en los storage?

estoy empezando en este mundillo

Tokens, datos de sesión no importantes, opciones de usuario...

ok. Si por ejemplo pongo un token y el rol, es dar demasiadas pistas igual

Si usas un token, asumo algo estilo JWT, por qué necesitas almacenar el rol también?

Esa información debería estar incluida en el payload del token

si, es un jwt

En el payload sólo metí el id del usuario

A no ser que necesites el rol en el frontend también

Hice el curso de Angular avanzado de Fernando Herrera

En ese caso, lo que suelo hacer yo es guardar un objeto user que lleva la información básica del usuario

Al iniciar sesión devuelvo los datos que voy a necesitar, me monto el user y lo meto al localStorage

Y ahí se queda hasta que cierre sesión

Cosas como el nombre de usuario, rol si quieres, el token y poco más

Cosas que en principio no van a cambiar a lo largo de la sesión

Nunca jamás guardes datos sensibles, eso es obvio

Podría acceder alguien desde el exterior al storage?

Podría el pc tener un troyano y que alguien lo viese todo?

Ok. Tienes razón, si tiene un troyano ya tienen acceso al equipo

xDD

Imaginemos que el usuario tiene su propia sesión en el pc y no es compartida con nadie

En principio, ese localStorage es seguro

De todas maneras, no debes almacenar en él datos privados

Pero un token jwt, sin problema

Si acceden al equipo, con nuestro token no tendríamos también un problema?

Podrían acceder pasando ese token, si meten un troyano

Pero eso ya se escapa a tu control

No se deben almacenar datos privados por si hay brechas de seguridad

El flujo que sigue Fernando Herrera no sé si es el habitual con los JWT

No sé quien es ese señor, ni lo que hace

accede con usuario/contraseña al backend, obtiene el token. Almacena el token en el storage y, si accedes a una página privada, envia ese token al backend para ver si tiene permisos o no (en caso contrario redirecciona al login)

Efectivamente

Eso es lo normal

El token se debe adjuntar en todas las peticiones que deben ser autenticadas

No sería más fácil, hablando de Angular, tener la clave también en el front para poder validar si es válida y no hacer tantas llamadas al backend?

Nooooooooooop

Nunca, jamás, almacenes una clave de usuario

Ni siquiera en el backend

Ah, no no. Me refiero a la clave de firma del JWT

Menos aun

El secret del JWT es lo único que da seguridad al JWT

Los JWT se pueden desmontar para ver qué llevan

Pero en principio el backend es seguro, no?

Lo único que le impide a nadie MODIFICARLO, es precisamente que va FIRMADO

Y si lo modifican, la firma no encajaría con el resto del JWT

Con lo cual sabes que alguien lo ha modificado

Por eso se deben validar en cada petición

Sí, eso lo entiendo. Pero si puedes realizar la validación del token también desde el backend evitarías llamadas al servidor

Buenas

El backend es seguro, si. Pondrías la mano en el fuego a que tu backend es seguro y nadie va a poder ver mi contraseña en texto plano si la almacenas?

El front no valida el token

Nunca

Porque si el front valida el token, cualquiera podría conseguir modificar la parte que valida el token y enviarte un token inválido, inventado

Y tu backend lo aceptaría porque es valido en front?

Buenas @abulafia!

@Trauma Eso que me ibas a preguntar ayer?

Hombre, se supone que si tienes la clave del JWT es que es una aplicación en la que confías. Sería como darle las llaves de tu casa a tu hermano

En principio no va a entrar y robarte

Si, si la llave fuese una serie de números y tu hermano se pasease con los números colgando del cuello a la vista de todos

Por eso me refiero, confias en el backend y le dejas tu clave secreta de JWT para descargarle de llamas

Las claves secretas nunca salen del backend

De hecho, lo normal sería ni siquiera tenerla en un archivo, si no en una variable de entorno

Pero esa clave es visible para todos en el frontend (que siempre digo backend por error)

ah, si. La tengo en una variable de entorno y accedo a ella por el proceso

Si puedo ver tu clave en el front, puedo armar mi propio JWT, hacerme administrador, y enviarlo a tu backend como válido

Pero es fácil de ver la info del front?

Quiero grabármelo a fuego en la mente.

Fácil o no... depende de los conocimientos que se tengan

Pero es posible

Basta con eso para no hacerlo

Basta con que UN usuario sepa hacerlo para que todo tu trabajo se vaya a la basura y dejes a un extraño acceder a datos privados de tus usuarios

eso sería una brecha de seguridad brutal

Es que exponer tus secretos al front, es una falta de seguridad grave xD

Entiendo. Yo pensaba que si tienes el front en un servidor privado y seguro no había problema

El front nunca está en un servidor privado

El front es lo que ve el usuario

@AntonioU. El front está en la máquina del usuario. El front es el navegador web, por ejemplo

Si estás hablando de angular, el front se carga en un navegador web, el usuario tiene acceso a todo él

Sí, hablo del caso de Angular

Pues qué importa donde lo alojas. Cuando me conecto a tu web, todo eso se carga en mi máquina

Como dijiste antes, eso hay que grabárselo a fuego. Una clave secreta NUNCA sale del backend

En el caso de una aplicación corriendo con Spring y que accede a servicios REST se aplicaría lo mismo, no?

Analogía: Una compañía de reparaciones. El backend son las oficinas que tiene en otra ciudad. El frontend es el técnico que se desplaza a tu casa. Angular es un maletín con herramientas que lleva el técnico. El técnico desde tu casa debe llamar a las oficinas en un momento dado para validar cosas

Correcto

imagina que, para ahorrar esas llamadas del técnico a la oficina decides que en su maletín lleve las claves apropiadas

¿y si mientras está en tu casa despistado tú le copias esa clave? O le robas el maletín?

la compañía debe actuar paranoicamente e imaginar que todos los usuarios son delincuentes, que van a secuestrar a sus técnicos y robarles los maletines de herramientas

y debe diseñar su plan de seguridad bajo esa hipótesis :-)

@abulafia jajajaja. Excelente manera de exponerlo

Ya lo pillo

He utilizado poco los JWT

Siempre he visto web tradicional: Spring o JEE con su base de datos sql y cookies de sesion

Aunque nunca he trabajado con tecnologías web

@AntonioU. El JWT no es muy diferente a una cookie de sesión, sólo que se transmite en otra cabecera

Efectivamente, es lo mismo en realidad

Harías el login en el front end? En realidad es posible. Una query a una DB remota y listo

jelou

Pero claro, entonces yo podría ver la conexión a la DB y enviar mi propia query modificada :D

Es lo mismo que mostrar la clave del JWT

@PabloLozano Jelou mucho

Una cosa que vi es que manda la password sin encriptar al backend. Luego la encripta y compara con la que tiene almacenada encriptada.

Eso no es inseguro, mandarla sin encriptar?

Si estás sobre una conexión https, realmente no

Por lo general, la contraseña se envía al backend sin encriptar siempre. Como mucho encodeada en base64

@AntonioU. Supongo que quieres decir aqui "hasheada"

@AntonioU. Y supongo que esa contraseña "sin encriptar" va por una conexión HTTPS, por lo que en realidad sí que va cifrada (junto en el resto de la comunicación). De lo contrario sería inseguro, sí

cuando la almacena la codifica con bcrypt, con un algoritmo de una sola via

A eso me refiero. Si enviara por http normal, ahí sería insegura

@AntonioU. "De una sola via", un hash entonces. Qué algoritmo?

lo miro

Si, bcrypt hashea las contraseñas

npmjs.com/package/bcrypt

Lo que haces para comprobar que es correcta es enviar la contraseña, volver a pasarla por bcrypt y comparar el resultado con lo almacenado en la DB

@AntonioU. node.bcrypt.js: A library to help you hash passwords.

hashear no es lo mismo que encriptar

Le vais a explotar la cabeza al chaval

xD

Yo siempre decía encriptar también...

Luego me explicaron que algo encritpado se puede desencriptar

Cuando hablamos de encriptar, nos referimos a que hay una forma de obtener los datos, entiendo? Hashear, sólo una via

No, está bien. Así aprendo cosas

@AntonioU. Efectivamente, algo encriptado se puede desencriptar con la clave correcta

un hash es una función "resumen". Te toma una secuencia de bytes de longitud arbitraria y te devuelve otra secuencia de bytes de longitud fija. Por eso es imposible volver hacia atrás, porque en el camino has perdido información. La idea detrás de una función hash es que dada la misma cadena de entrada, producirá siempre la misma cadena como resultado

Yo es que vengo del mundo del Cobol

tecnología de Atapuerca

por eso puedes comparar dos hashes y si son iguales sabes que (con toda probabilidad) provienen de la misma cadena de entrada

la misión de la encriptación es "desfigurar" los datos, por así decir, para que quien lea la versión cifrada no pueda conocer cuáles eran los datos originales. Pero quien conozca la clave de desencriptación sí podrá recuperarlos

Ok. Joder, pues muchas gracias. Me habéis ayudado muchísimo

la misión del hash en cambio es "resumir" información de longitud arbitraria a un número de bits comparativamente pequeño

Voy a seguir con las cosillas que tengo que hacer. Oye, muchas gracias de verdad

eso se puede usar para muchas cosas, normalmente para poder comparar dos cosas sin necesidad de comparar las cosas en sí, sino sus hashes

Estoy aprendiendo por mi cuenta cosas y es complicado. Principalmente a base de cursos de Udemy

puedes saber si un fichero de 2.5GB ha sido modificado sin necesidad de guardar una copia del fichero, basta guardar una copia de cuál era su hash

de vez en cuando puedes volver a hashear el fichero y si te sale el mismo hash que tenías almacenado, es que nadie lo ha tocado. Bastaría cambiar 1 bit en los 2.5GB y el hash que saldría sería completamente diferente

Entiendo

eso también se usa para verificar firmas digitales

tiene muchos usos. Uno de ellos es evitar almacenar contraseñas de usuario

Las famosas clave pública-privada

bueno, me voy. Luego me conecto un ratillo. Buen día y gracias de nuevo :)

lo de las claves pública-privada sí que son para cifrar/descifrar. No son hashes, aunque sulene usarse combinadas con hashes para el caso de la firma digital

El mundo de la seguridad desde fuera parece complejo, pero es algo engañoso: es mucho más complicado de lo que puede parecer.

@abulafia @PabloLozano Ahora que estais, a ver si tenéis experiencia en esto: ¿ Como reemplazar un programa en ejecución, con conexiones abiertas, por una versión distinta ? Sin perder las conexiones, claro :-)

No es para eso exec() y todos sus primos?

eso conserva la tabla de descriptores del proceso

¿ Y enviar los datos asociados a cada conexión ?

Los sockets en si se que se heredan

Un protocolo propio para eso, entiendo

Yo experiencia cero, piensa que al trabajar con aplicaciones web el protocolo no es orientado a la conexión

... ummm ...

Tendre que crear el protocol pues

bueno, mas se perdio en la guerra

(dicen, yo no estuve allí)

cuando se despliega algo se hace un "drenado" del pod (no se admiten conexiones en ese pod, todas se pasan al resto vía balanceador) hasta que todas las existentes se cierran

y entonces se despliega

y se repite para cada pod

no no, es en local

así que con HTTP no hay mucho problema

vale. Mas o menos lo que tenía previsto/pensado

un poquito de curro extra

@Trauma Un poco de curro extra nunca mató a nadie

Eso dicen

Está pendiente de demostración :-)

Pues intenta no demostrarlo personalmente... no debe ser bueno para la salud xDD

ayer con un par de esas respuestas básicas que se vuelven populares tengo una muesca más para la medalla Epico :D

a este ritmo en 5 años la tengo!

xDDDD

Ya te falta menos :-)

Alguien tira una mano cerrando esta pregunta? es.stackoverflow.com/questions/423544/…

13/50

Si veis su perfil, su otra pregunta es exactamente el mismo problema

Oh, la ha borrado D:

Nunca voy a poder cerrar preguntas

la había cerrado yo

al ser de JS, tengo el martilllo dorado

Cerrada hace 14 minutos por Benito-B, Pablo Lozano

la borró despues de haberse cerrado

@Benito-B You can't always get what you want

@PabloLozano ¬¬

A mi es que las cosas doradas no me van mucho

Pero gracias xD A ver si me saco la medalla

no te cuenta si soy uno de los que votó? de todos modos espera un poco, que las medallas se dan con minutos de retraso

@Benito-B pues la cuesta es empinada. Pablo se la ganó a punta de respuestas. XD

Ah, pensaba que hablábamos de una medalla por primer cierre

Que asco son los Boost Tests. Prefiero los de Google

O será porque no se usarlos

pero son un latazo para comprobar los fallos

@PabloLozano Si, habría jurado que había una medalla por cerrar/reabrir preguntas

Pero ahora no la veo

@Benito-B Con la de Oro de la etiqueta puedes cerrarlas tu solito, sin necesitar 5 votos

para reabrir, son 5 votos

y para recuperar, creo recordar que tambien son 5

Ah, no sus lo he dicho

ayer me llamó uno de los jefazos

van a hacer lo posible para sacarme de aquí y meterme en algo de BigData de verdad

o en los proyectos de REE, lo que antes pase

@Trauma Joder, felicidades

¡ Asssiiiaaaassssss !

Tanto te quejas que el jefe no te hace caso y mira

O aprendo BigData, o recupero mi horario de señorito xD

no no, el jefecillo, que es otra cosa

Ahhh

Hostia, si vas a big data y tienes suerte, lo mismo tienes que aprender python

La verdad es que la jefaza de people es buena gente

@Benito-B jejeje ... nuestro primer semi-curro aquí fue hacer un analisis de sentimiento de tweets

fue una trabajillo para que perdieramos el miedo a BigData

el script final, lo hice en python

:O

mayormente, porque no encontré sistemas entrenados para analisis de sentimiento en otros lenguajes

Me he quedado como tu avatar

no estuvo mal, pero ya no me acuerdo de la herramienta que usamos para conectar twitter y nuestro bischo

y kafka para encolar twetts

y un python al final que extraia de kafka y analizaba

lo monté todo, incluido el servidor kafka

fueron 2 semanitas guapas

Bueno, pues a esperar órdenes del jefecillo

mientras, voy a probar a compilar esto en Release

a ver que pasa

¿ Se nota que me aburro mucho ?

Lo digo por lo de hablar solo y eso