Mensajes

Si, eso ya lo he dicho yo. Esta más que claro que se puede robar la información de inicio de sesión, ya sea la contraseña en texto plano o el hash y con cualquiera de los dos iniciar sesión. Pero entre que roben la contraseña en texto plano o un hash, es mucho mejor que solo sea el hash, ya que aunque existen tablas donde "pueda" (no es 100% seguro) estar la contraseña en texto plano, hay menos riesgo de que quede expuesta la contraseña del usuario y se use para entrar en otras webs/servicios online (porque como ya sabemos la mayoria solemos usar la misma  ).

De todas maneras, a mí personalmente, no me hace ninguna gracia que mi contraseña (o cuenta bancaria, etc) se envie en texto plano, aunque sea mediante una conexión cifrada usando TLS. ¿Por que? Muy sencillo:

1º TLS ni ningún predecesor será 100% seguro, siempre habrá alguna manera de romper el cifrado o engañar al sistema y no creo que haga falta mencionar ataques conocidos que aún se siguen usando.

Solo con eso ya hay razón más que suficiente como para no mandar información sensible en texto plano.

2º (y no menos importante) Mi contraseña o cualquier otro dato sensible, deben ser secreto incluso para la empresa que ofrece el servicio. ¿Quien te asegura que esos datos que llegan al servidor, no son guardados en texto plano antes de ser hasheados/cifrados? (¿Enserio nadie habia pensado en esto antes? Debe ser que tengo una mente retorcida )

Lo dicho, a mi personalmente no me hace ninguna gracia.

HTTPS no es una medida infalible, es simplemente una capa más de seguridad que debe usarse como refuerzo sobra la seguridad que ya hayas implementado.

Hola, si PHP y la base de datos los tienes en el mismo servidor no hay por qué preocuparse por el intercambio entre estos dos servicios ya que ambos se encuentran en el mismo equipo, otra cosa sería que estuviesen en distintos servidores.

Probablemente te refieras a la comunicación entre el cliente (el navegador del usuario) y el servidor. Actualmente no hay ninguna manera infalible, ya que se pueden robar los datos con una facilidad increible. Lo que hay que conseguir es que esos datos "secretos" estén cifrados de la mejor manera posible, pero desgraciadamente el que sepa va a poder saber lo que se envia.

Usa una libreria segura, como crypt o sha512 para hashear la contraseña, lo demás tambíen puedes hashearlo pero no suele hacerse.

No vale de nada hashear una contraseña en el servidor, ya que los datos ya han sido enviados en texto plano... Si, claro, para no guardarla tambien en texto plano, pero el daño ya está hecho. Aquí tienes una buena implementación en javascript de SHA.

Para protegerse de las tablas rainbow, podria saltearse el hash también en el cliente (y de nuevo en el servidor por si se roba y se usa para iniciar sesión), pero el problema sería de donde sacas el primer salt y como lo envias al servidor... Estaríamos en las mismas. Si a alguien se le ocurre como solucionar este problemilla que lo comparta.

En el cliente:
- Contraseña -> javascript -> SHA512 hash -> POST.

En el servidor:
- Generar random salt -> Saltear hash (hashear de nuevo el hash junto al salt).

Si necesias un ejemplo luego lo pongo.

Hola, estoy teniendo problemas para configurar los permisos del directorio document root de apache.

Creé un usuario para usar el ftp y le cambie el dueño a la carpeta /srv/http a mi usuario para poder subir los cambios, pero ahora resulta que apache no tiene permisos de escritura (mkdir() da error de permisos).

¿De qué manera puedo configurar los permisos del document root (/srv/http) para que tanto apache (http) como mi usuario puedan tener permisos? ¿Quien debería ser el dueño del directorio? ¿Root, http o yo?

Gracias.

No se trata de que sea irrompible o no. MD5 no se recomienda porque es rápido y por lo tanto un atacante podría comparar billones de hashes por segundo con una sola gpu...

Se podrá siempre que se disponga de la contraseña original. Si nadie ha cifrado la contraseña y ha apuntado el hash en un diccionario es imposible de romper.  

MD5 is one way encryption, que significa que solo se puede cifrar y no descifrar. Romper no significa que se ha descifrado, si no que se ha encontrado una coincidencia. Como bien sabemos, se hashean contraseñas al azar y se guardan en diccionarios para luego comparar. A eso se le llama fuerza bruta (al igual que 0000, 0001, 0002...  ).

Dejo una guia actualizada para hashear las contraseñas, incluye como usar argon2: https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016#php

Lo del orden de los bloques ya lo entiendo, se trata de poner primero el bloque *:80 y *:443 con servername localhost (y un document root con un index.html "it works" o lo que sea) y luego los demás bloques. De esta manera cualquier nombre que no coincida irá a los dos primeros.

Si, exacto, es lo que tenia en mente, usar el sistema que tiene debian (y derivados) para administrar los vhosts.

Los indices los tengo en cada bloque directory dentro de cada bloque virtualhost, de esta manera cada dominio/subdominio tiene su propio indice (por ejemplo el subdominio static no necesita php, pero los demás si).

El -Indexes está en el archivo de configuración principal (httpd.conf) en su bloque directory /srv/http (osea desactivado el indexamiento de apache de manera global y no tener que desactivarlo para cada dominio/sbudominio).

PHP lo tengo por mod_proxy_fcgi y php-fpm, aunque la configuración cgi no la he tocado (la verdad es que todavia no tengo ni idea de para que sirve ), todo está funciona perfectamente.

Al final resulta que el server alias no lo voy a necesitar, ya que el dominio sin www lo voy a dejar que redireccione automaticamente a www y puerto 443 (gracias a let's encrypt por darnos certificados gratis  ). Y de paso también activo HTST (y me falta una opción de seguridad más que no recuerdo):

Código [Seleccionar] Expandir

<VirtualHost *:80>
   ServerName example.com
   Redirect permanent / https://www.example.com/
</VirtualHost>

<VirtualHost *:443>
   ServerName example.com
   Redirect permanent / https://www.example.com/
   SSLEngine On
   # etc...
   Header always set Strict-Transport-Security "max-age=15768000"
</VirtualHost>

<VirtualHost *:443>
   ServerName www.example.com
   DocumentRoot /usr/local/apache2/htdocs
   SSLEngine On
   # etc...
   Header always set Strict-Transport-Security "max-age=15768000"
</VirtualHost>

Lo dejo por si a alguien le surge el mismo problema. Al final he conseguido hacer que funcione, pero sigo sin entender por qué no funciona usando los nombres de dominio en los bloques:

Usando asterisco y el puerto (por si usas SSL):

Código [Seleccionar] Expandir

#1st block
<VirtualHost *:80>
     ServerName  localhost
</VirtualHost>

#2nd block
<VirtualHost *:80>
     ServerName  mydomain.com
</VirtualHost>

#3rd block
<VirtualHost *:443>
    ServerName  mydomain.com
</VirtualHost>

#4th block
<VirtualHost *:443>
    ServerName  sub1.mydomain.com
</VirtualHost>

#5th block
<VirtualHost *:443>
    ServerName  sub2.mydomain.com
</VirtualHost>

http://mydomain.com/ y https://mydomain.com/ ambos irán al tercer y cuarto bloque, respectivamente. Pero http://www.mydomain.com/ y https://www.mydomain.com/ ambos irán al primer bloque ya que no se declaró ServerAlias a www.mydomain.com en ambos bloques. Los subdominios solo funcionarán por https, si intentas acceder por el puerto 80 llevará al primer bloque. Espero que se entienda el ejemplo que puse.

Ah vale pues perfecto, compraré uno que sea 1 cable solo en lugar de doble, ya que para que quiero uno colgando?  

Hola buenas, resulta que tengo un pequeño problema, me he puesto a hacer limpieza y a cambiar de sitio los altavoces de mi ordenador, para que esten bien posicionados y resulta que se me ha quedado corto el cable del altavoz satélite central.

Tienen conector RCA (sin color) y van conectados al subwoofer. Mi pregunta es, si compro un simple alargador, ¿funcionaria?

¿Alguien sabe de algún sitio web donde vendan?

Gracias!

Pues yo tampoco tengo ni idea de como funciona una calculadora por dentro  Hice (en su dia) calculadoras en C, alomejor así es como funcionan, un script, ni idea.

Uso mi propio framework, empecé a programar por mi cuenta y me gusta conocer el código que uso en mis aplicaciones. Para eso no hay nada mejor que hacerlo todo tu mismo. ¿Reinventar la rueda? Sip (o no, como se mire  ), pero no me importa, así voy aprendiendo cada vez más y más y haciendo mi código más seguro.

Sé lo que significa "bajo nivel" en lo referente a lenguajes de programación y su relación con el hardware, pero PHP es un lenguage de nivel alto y no tiene comunicacion alguna con el hardware, ¿a que te refieres entonces?

Aunque creo que te refieres a lo ultimo que has comentado, código que no conoces ejecutandose... Y para leerme el framework entero prefiero mantenerme informado sobre seguridad y aplicarla yo mismo a mi propio código.

Para ello debes implementar url routing con php. Pero hay un pequeño problema, ya no podrás usar el indexamiento de apache, osea navegar por las carpetas (por ejemplo website.com/css/sytles.css), por lo que tendrás que crearte un subdominio para servir el contenido estático. Lo bueno es que es más seguro.

Yo lo tengo de la siguiente manera:

página principal y si tienes subdominios que requieran esto también:

Código (apache) [Seleccionar] Expandir

<IfModule dir_module>
   DirectoryIndex index.php
</IfModule>

<IfModule mod_rewrite.c>
   RewriteEngine On
   RewriteBase /
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteRule ^index\.php$ - [L]
   RewriteRule . index.php [L]
</IfModule>

Y para el subdominio estático (yo lo llamo static.website.com):

Código (apache) [Seleccionar] Expandir

<Files *>
   SetHandler default-handler
</Files>

<IfModule dir_module>
   DirectoryIndex index.html
</IfModule>

<IfModule mod_headers.c>
   SetEnvIfNoCase Origin: "https?://(www\.)?(website\.com|subdominio\.website\.com )(:\d+)?$" ACAO=$0
   Header set Access-Control-Allow-Origin: "%{ACAO}e" env=ACAO
   Header set Access-Control-Allow-Methods: "GET"
</IfModule>

Lo primero es sencillo de entender, lo que hace es redirigir todas las peticiones al index.php, que ahora es el router (en lugar de apache, por eso ya no funcionará website.com/css/styles.css).

Lo segundo lo que hace es: primero desactiva php (no se necesita) y activa CORS para que se puedan hacer peticiones get para cargar los archivos estáticos (ya sean imagenes, javascript, css, etc...). Donde dice website lo cambias por el nombre de tu web y donde dice subdominio por el nombre de tu subdominio.

Esa era la configuración de Apache, ahora viene la parte de programación PHP. Esto ya lo he explicado anteriormente, te dejo un enlace: http://foro.elhacker.net/php/incluir_metadatos_de_forma_dinamica-t454368.0.html;msg2077138#msg2077138 Aquí explico en detalle como hacerlo, cualquier cosa que no entiendas no dudes en preguntarlo, eso sí, ordenadas una por una las dudas y no todas juntas