[Previo por Fecha] [Siguiente por Fecha] [Previo por Hilo] [Siguiente por Hilo]
[Hilos de Discusión] [Fecha] [Tema] [Autor]Sandino, muchas gracias :), ta chida la info :) De hecho, ya me puse a trabajar en unas pequeñas librerias para php, que creen el id con el md5 y verifiquen la ip. Seguimos por aki ... On Tue, Jun 25, 2002 at 12:04:39PM -0500, Sandino Araico Sánchez wrote: > Esto me lo encontré en webappsec en securityfocus com, viene mejor explicado > cómo hacer buenas variables de sesión y cómo usar transacciones.... > > Subject: > RE: Alternatives to session IDs as authenticators? > Date: > Wed, 24 Apr 2002 13:20:29 -1000 > From: > "Jason Coombs" <jasonc en science org> > To: > "Eric Thomas" <eric en psteering com>, <webappsec en securityfocus com> > > Aloha, Eric. > > Session identifiers are not authentication if they are generated > according to a predictable algorithm. Consider, however, what a > user ID and password pair look like in bits. Most session IDs > have more bits than a user ID and password do. Therefore they > are more "secure" than a user ID and password, in terms of a > malicious third party attacker being able to guess or randomize > valid bits. SSL-security combined with random session identifiers > of variable length represent very good security. > > One technique commonly employed to make session identifiers more > secure is to generate the random number and hash it with a secret > key and a keyed hash algorithm then attach the hash code to the > random number and call the combined bit sequence the session ID. > This way the server can validate the session ID and it is not > practical for attackers to randomize both the random number and > the keyed hash code. > > Microsoft ASP.NET uses this technique in its Forms Authentication > mechanism, and .NET Passport use a similar technique. The user > sends credentials to authenticate once with the server, and from > that point forward the client sends only the authentication ticket > assigned to it following authentication of the credentials. The > ticket is not a simple random number, it includes a keyed hash > that only the server can verify because only it knows the secret > key used when applying the keyed hash algorithm -- only the server > can rehash the random number provided in the ticket to confirm > the authenticity of the hash provided in the ticket. > > When SSL is not used, there are known problems with proxy cache > where multiple clients receive the same session IDs by way of > either cookies or URL-encoding, and man in the middle attacks > succeed in compromising session IDs because they are sent as > plaintext to and from the server. HTTP authentication must be > used, either basic or digest, with unencrypted HTTP sessions > because there is no way for the server to generate a session > ID and deliver it securely to the client such that it can be > relied upon as a shared secret -- the client must supply valid > credentials with every HTTP request, and those credentials are > used as the shared secret. Anything the server sends back to > the client without encryption is no longer a shared secret. > > As for replay attacks when SSL is not used, the only defense > against such attacks is session ID expiration. As long as the > server believes the session identifier or authentication > ticket to be valid, the replay attack succeeds. You can SSL > secure the authentication event where credentials are sent > by the client to the server, but if you intend to allow the > client to browse without SSL, the authentication ticket will > have to be sent in the clear with each request and replay > attacks become possible. Cookies are marked as either SSL > secured or not, and those that are don't get sent in client > requests that aren't, so dropping a cookie after an SSL > secured authentication event that is marked secure isn't > enough, you must also direct the client to an http URL > where another cookie gets dropped. > > NET Passport implements such a dual-cookie system for sites > that require SSL-secured credential transport but that need > to allow browsing with the authentication ticket to http > URLs as well. Both .NET Passport and ASP.NET Forms > Authentication expire authentication tickets and replace > them periodically. The user automatically receives the new > ticket and stops sending the old one. > > Aloha & Mahalo, > > Jason Coombs > jasonc en science org > > MiG wrote: > > > Hola a todos ¡ > > > > Quisiera pedirles su opinion respecto a las sesiones en php, ¿Que tan > > seguras son?, he leido en algunas partes que no son tan seguras y son > > muy explotables. Y si alguien tiene una liga por ahi de como funcionan > > (no como usarlas, sino como trabajan) se lo agradeceria mucho. > > > > Seguimos por aki ... > > > > _______________________________________________ > > Ayuda mailing list > > Ayuda en linux org mx > > Para salir de la lista: http://mail.linux.org.mx/mailman/listinfo/ayuda/ > > -- > Sandino Araico Sánchez > - Piensa en grande > - Comienza en pequeño > - Escala rápido > > _______________________________________________ Ayuda mailing list Ayuda en linux org mx Para salir de la lista: http://mail.linux.org.mx/mailman/listinfo/ayuda/