Search Results

Search found 2 results on 1 pages for 'javafueled'.

Page 1/1 | 1 

  • Help needed in grokking password hashes and salts

    - by javafueled
    I've read a number of SO questions on this topic, but grokking the applied practice of storing a salted hash of a password eludes me. Let's start with some ground rules: a password, "foobar12" (we are not discussing the strength of the password). a language, Java 1.6 for this discussion a database, postgreSQL, MySQL, SQL Server, Oracle Several options are available to storing the password, but I want to think about one (1): Store the password hashed with random salt in the DB, one column Found on SO and elsewhere is the automatic fail of plaintext, MD5/SHA1, and dual-columns. The latter have pros and cons MD5/SHA1 is simple. MessageDigest in Java provides MD5, SHA1 (through SHA512 in modern implementations, certainly 1.6). Additionally, most RDBMSs listed provide methods for MD5 encryption functions on inserts, updates, etc. The problems become evident once one groks "rainbow tables" and MD5 collisions (and I've grokked these concepts). Dual-column solutions rest on the idea that the salt does not need to be secret (grok it). However, a second column introduces a complexity that might not be a luxury if you have a legacy system with one (1) column for the password and the cost of updating the table and the code could be too high. But it is storing the password hashed with a random salt in single DB column that I need to understand better, with practical application. I like this solution for a couple of reasons: a salt is expected and considers legacy boundaries. Here's where I get lost: if the salt is random and hashed with the password, how can the system ever match the password? I have theory on this, and as I type I might be grokking the concept: Given a random salt of 128 bytes and a password of 8 bytes ('foobar12'), it could be programmatically possible to remove the part of the hash that was the salt, by hashing a random 128 byte salt and getting the substring of the original hash that is the hashed password. Then re hashing to match using the hash algorithm...??? So... any takers on helping. :) Am I close?

    Read the article

  • Can I turn off an Apache Directive then turn it on in an include?

    - by javafueled
    I have a VirtualHost block that includes common configuration items, one directive is ProxyPreserveHost. Can I "procedurally" turn off ProxyPreserveHost for a Rewrite directive then have the include turn it back on? For example: <VirtualHost *:80> ServerName www.blah.com ... ... ProxyPreserveHost off RewriteRule /somepath http://otherhost/otherpath [P] Include /path/to/file/turning-on-ProxyPreserveHost </VirtualHost> The otherhost is on a CDN and preserving the host is creating some name resolution issue that is not allowing the proxying of content in the host namespace. ProxyReserveHost is only allowed in a Server Config or VirtualHost. It doesn't look like I can selectively turn it off for the ProxyPass and ProxyPassReverse directives (encapsulated in the proxy flag of mod_rewrite).

    Read the article

1