Re: [aur-dev] [PATCH] add search only by name and use it as default

2010-04-15 Thread Loui Chang
On Wed 10 Mar 2010 20:01 +0100, Andrea Scarpino wrote:
 On Wednesday 10 March 2010 19:50:25 Nathan Wayde wrote:
  Please don't make it name-only by default, the search is crappy enough
  already without the extra effort to make it kinda-work-sorta.

 I think is better to search by name as default.

Please test your patches!

Missing a closing parenthesis:
+   $q.= AND (Name LIKE '%.$_GET['K'].%' ;

Also, the default should remain name and desc even when opening up the
advanced search, so it should be the first option in the combobox.

Thanks for the patch. I've applied those changes.


Re: [aur-dev] [PATCH] Support for salted passwords

2010-04-15 Thread Simo Leone
I don't want to confuse the issue by introducing another, but while we're on
the topic...

A salt is exactly what Dan described, the salt value is not secret, in fact
it's usually stored right next to the hashed password, or concatenated to
it, in many cases. To put it in a more concrete sense let h(x) = hash of
string x , S=a salt value, and P=plaintext password (and ^ is
concatenation). Typically what you store in the database for salted
passwords is : S ^ h(S^P)

There is another related concept, called pepper, which introduces a very
small amount of random data which is not recorded anywhere, but is
concatenated to the salted password prior to hashing. Typically a byte or 4
bits of data are used for this. The idea being that it is relatively
inexpensive for the server to try up to 256 different peppers... but for a
bruteforce attacker it adds 2 orders of magnitude more guessing per
password. For these, what you store in the database is : S ^ h(pepper ^ S ^
P) .

-Simo

On Thu, Apr 15, 2010 at 2:10 PM, Dan McGee dpmc...@gmail.com wrote:

 On Thu, Apr 15, 2010 at 2:00 PM, Loui Chang louipc@gmail.com wrote:
  On Mon 05 Apr 2010 09:50 -0400, Denis Kobozev wrote:
  Here's a patch that adds support for storing salted passwords in the
  database. The salt is a random string for each user and is stored
  along with the password in the Users table. Salt is created and
  password is salted when old users log in. New users get salted
  passwords when they register. What do you think?
 
  Hi Denis. I thought the idea behind salt is that if someone gets the
  database, they can't crack the passwords because the salt is secret.
 
  If you include the salt in the database, then it wouldn't be much more
  difficult to crack than the regular password hash, would it?  So how
  would we go about keeping the salt secret if it's in the same database
  as the password hashes?
 
  I might not fully understand the concept though.

 That's not fully correct. Salt is not meant to be secret; it is meant
 to prevent the use of rainbow tables or precomputed hashes.

 The idea behind salt in this case is for each user's password to be
 hashed with a different salt. This means if someone is to crack one
 person's password, it doesn't help them at all with the remaining
 passwords in that same database that they got their hands on because
 the salt is unique for every user.

 -Dan