How To Safely Store A Password

Post by nerfhammer » Fri, Jul 01, 2011, 2:58 PM UTC

roel_v wrote: post #116

InclinedPlane wrote: post #33

Earlier quoted context omitted.

With smartphones this is increasingly feasible. Lots of sites already use smartphone based two factor authentication (similar to rsa keys). There's no reason why a challenge / response system couldn't be set up using smartphones. For example, a website gives you a string of numbers, you input those in your smartphone app and get the response which yiu then input back to the site, the site can't determine the response…

This is how blizzard (World of Warcraft) authenticators work. It's quite ironic how an online game has strong security mechanisms, yet many tools that people use just as often or more (gmail, facebook, pretty much all SaaS tools, including business) and that are are certainly more 'important' (in an objective sense, I understand that people are more attached to their WoW character than to their customer database) don…

Post by owenmarshall » Fri, Jul 01, 2011, 3:05 PM UTC

JoachimSchipper wrote: post #66

WA wrote: post #64

Earlier quoted context omitted.

An idea would be to use a JavaScript implementation of bcrypt to let clients do the math themselves and just send the encrypted password via HTTPS. This has several advantages. One being that the server-side performance is reduced heavily. Another one is that a password never shows up on the server in plaintext ever. Disadvantage: Clients need to have JavaScript enabled.

That doesn't work. Among other issues, Javascript is so much slower than C or CUDA at such tasks (no native integers!) that the client is going to take forever to calculate a sufficiently-hard hash.

Post by nerfhammer » Fri, Jul 01, 2011, 3:09 PM UTC

vog wrote: post #78

iki23 wrote: post #75

Earlier quoted context omitted.

You can also initialize the words in more pythonic way: with open('/usr/share/dict/words') as wordlist: words = set(line[:-1] for line in wordlist) Or, for one time check you can stop reading on match: import sys lookup = '%s\n' % sys.argv[1] with open('/usr/share/dict/words') as wordlist: [ sys.stdout.write('Dictionary password: %s' % lookup) or sys.exit(1) for line in wordlist if line == lookup ] As for the objecti…

While I agree that the first code is pythonic and nice, the second code is quite the opposite of that. Why forcing imperative code into a list comprehension? It is a lot easier to read as nested loop, as it doesn't build a dummy list with some strange "or" operation: import sys lookup = '%s\n' % sys.argv[1] with open('/usr/share/dict/words') as wordlist: for line in wordlist: if line == lookup: sys.stdout.write('Dict…

  import pickle

  # initialize:
  wordset = frozenset(line.lower().rstrip() for line in open('/usr/share/dict/words'))
  pickle.dump(wordset, open('/tmp/wordset.pkl', 'wb', -1))

  # when you want to use it:
  wordset = pickle.load(open('/tmp/wordset.pkl', 'rb'))

  'bear' in wordset # == True

Post by owenmarshall » Fri, Jul 01, 2011, 3:12 PM UTC

roel_v wrote: post #135

brown9-2 wrote: post #104

Earlier quoted context omitted.

Then how in the world does your code know what salt to use when the user presents his or her password? If it is derived in code from some other piece of user data then it is still "known" if your DB leaks - you have to assume someone who stole your database also stole your code.

"you have to assume someone who stole your database also stole your code." Maybe, but that doesn't mean that a separate salt, not in the database, will prevent certain attacks, and as such is a viable option. Security is about layering, not about 'xyz isn't 100% secure in 100% of the cases, forget about it'.

Post by bradleyland » Fri, Jul 01, 2011, 3:15 PM UTC

praptak wrote: post #136

brown9-2 wrote: post #104

Earlier quoted context omitted.

Then how in the world does your code know what salt to use when the user presents his or her password? If it is derived in code from some other piece of user data then it is still "known" if your DB leaks - you have to assume someone who stole your database also stole your code.

"Then how in the world does your code know what salt to use when the user presents his or her password?" It brute forces the missing part. Obviously you may only leave out a number of bits that keeps it feasible.