Storing passwords

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Storing passwords

Paco Willers

Hi,

I would like to store passwords in my Lua 5.1 application. For example as an MD5 hash. I managed to do that with  luacrypto. I wish to continue my developing on a server which doesn't have the crypto C library installed which luacrypto depends on, so I cannot use luacrypto here. Is it possible to do hash encrypting in a Lua-only manner? On the Lua wiki I saw an article: it is possible with Lua 5.2. Can I switch to Lua 5.2 and still use Lua modules/libs that are written for Lua 5.1? (luasocket, coxpcall, copas) Any tips are welcome.

Have a nice day, :-)
Paco

Reply | Threaded
Open this post in threaded view
|

Re: Storing passwords

Philippe Lhoste
On 21/05/2012 15:04, Paco Willers wrote:
> I would like to store passwords in my Lua 5.1 application. For example as an MD5 hash.

A hash doesn't allow you to store passwords, it only allows to verify a provided password
is identical to the expected one. You can't get back a password that have been hashed.
If your goal is only to check passwords, that's OK.

> managed to do that with  luacrypto. I wish to continue my developing on a server which
> doesn't have the crypto C library installed which luacrypto depends on, so I cannot use
> luacrypto here. Is it possible to do hash encrypting in a Lua-only manner? On the Lua wiki
> I saw an article: it is possible with Lua 5.2. Can I switch to Lua 5.2 and still use Lua
> modules/libs that are written for Lua 5.1? (luasocket, coxpcall, copas) Any tips are welcome.

Indeed, Lua 5.2 has binary operators allowing to compute MD5 or similar algorithms.
Probably slower than a C version, but I suppose you won't check thousands of password per
second, so it should be OK.

AFAIK, most Lua libraries with native C code will need to be recompiled for Lua 5.2. I had
to do that for lfs, luasocket, lpeg...

--
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --


Reply | Threaded
Open this post in threaded view
|

Re: Storing passwords

Paco Willers
2012/5/21 Philippe Lhoste <[hidden email]>
A hash doesn't allow you to store passwords, it only allows to verify a provided password is identical to the expected one. You can't get back a password that have been hashed.
If your goal is only to check passwords, that's OK.

My goal is to check passwords indeed, and to prevent storing them as plain text.
 
Indeed, Lua 5.2 has binary operators allowing to compute MD5 or similar algorithms. Probably slower than a C version, but I suppose you won't check thousands of password per second, so it should be OK.

AFAIK, most Lua libraries with native C code will need to be recompiled for Lua 5.2. I had to do that for lfs, luasocket, lpeg...

Just tried for fun, luasocket indeed won't do out of the box on Lua 5.2. So I'm back to 5.1, never change a winning team. :-)

Thanks for your reply, and I'll continue my search for pure Lua code that encrypts or hashes a password, or create one myself. Maybe I'll find code that emulates binary operators, although IMHO that would be an extremely slow solution.

--
Paco
Reply | Threaded
Open this post in threaded view
|

Re: Storing passwords

Tomás Guisasola-2
In reply to this post by Philippe Lhoste
  Hi Paco

On Mon, 21 May 2012, Philippe Lhoste wrote:

> On 21/05/2012 15:04, Paco Willers wrote:
>>  I wish to continue my developing on a
>>  server which
>>  doesn't have the crypto C library installed which luacrypto depends on, so
>>  I cannot use
>>  luacrypto here. Is it possible to do hash encrypting in a Lua-only manner?
>>  On the Lua wiki
>>  I saw an article: it is possible with Lua 5.2. Can I switch to Lua 5.2 and
>>  still use Lua
>>  modules/libs that are written for Lua 5.1? (luasocket, coxpcall, copas)
>>  Any tips are welcome.
>
> Indeed, Lua 5.2 has binary operators allowing to compute MD5 or similar
> algorithms. Probably slower than a C version, but I suppose you won't check
> thousands of password per second, so it should be OK.
>
> AFAIK, most Lua libraries with native C code will need to be recompiled for
> Lua 5.2. I had to do that for lfs, luasocket, lpeg...
  If you don't mind using a C library with a binding for Lua,
you should try md5:

http://www.keplerproject.org/md5/

  It can also be installed via LuaRocks:

http://luarocks.org/repositories/rocks/#md5

  Regards,
  Tomás
Reply | Threaded
Open this post in threaded view
|

Re: Storing passwords

Luiz Henrique de Figueiredo
> If you don't mind using a C library with a binding for Lua,
> you should try md5:
>
> http://www.keplerproject.org/md5/

You can also use my lmd5, which can use any MD5 library that uses the
traditional C API. There is public domain code for it. If you're
interested, please let me know.
        http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/#lmd5

Reply | Threaded
Open this post in threaded view
|

Re: Storing passwords

Tony Finch
In reply to this post by Philippe Lhoste
Philippe Lhoste <[hidden email]> wrote:
>
> A hash doesn't allow you to store passwords, it only allows to verify a
> provided password is identical to the expected one. You can't get back a
> password that have been hashed.
> If your goal is only to check passwords, that's OK.

No, don't use a bare hash for storing passwords. Use the standard crypt()
function, or if you want to be even safer use bcrypt or scrypt.

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Plymouth: Variable 3 or 4. Slight or moderate. Fog patches. Moderate or good,
occasionally very poor.

Reply | Threaded
Open this post in threaded view
|

Re: Storing passwords

Luiz Henrique de Figueiredo
In reply to this post by Paco Willers
> Thanks for your reply, and I'll continue my search for pure Lua code that
> encrypts or hashes a password, or create one myself. Maybe I'll find code
> that emulates binary operators, although IMHO that would be an extremely
> slow solution.

There is a backport of the 5.2 bitlib for Lua 5.1. I think it was posted here.
Please serch the archives.

Reply | Threaded
Open this post in threaded view
|

Re: Storing passwords

Petite Abeille
In reply to this post by Paco Willers

On May 21, 2012, at 7:09 PM, Paco Willers wrote:

> I'll continue my search for pure Lua code that
> encrypts or hashes a password,

Perhaps a relatively slow, pure Lua implementation could be viewed as a feature in that specific case:

http://equi4.com/md5/md5calc.lua
http://luaforge.net/projects/sha1-rsa/


> or create one myself.

Don't. Use bcrypt or such:

https://github.com/silentbicycle/lua-bcrypt

If you insist doing it yourself, some food for thoughts:

Salted Password Hashing - Doing it Right
http://crackstation.net/hashing-security.htm


Reply | Threaded
Open this post in threaded view
|

Re: Storing passwords

Paco Willers
SOLVED!

Thanks to all!

I now use http://www.keplerproject.org/md5/. The md5.sumhexa(message) function is what I was looking for. This library also contains several other functions which have my interest.

About bcrypt and others... As mentioned, they are safer, but as long as my application in development (a telnet game) receives transmitted passwords as plain-text, there is a new challenge for me to solve that first. :-)

Have a nice day,
--
Paco
Reply | Threaded
Open this post in threaded view
|

Re: Storing passwords

Jay Carlson
On May 21, 2012, at 4:19 PM, Paco Willers wrote:
>
> I now use http://www.keplerproject.org/md5/. The md5.sumhexa(message) function is what I was looking for. This library also contains several other functions which have my interest.
>
> About bcrypt and others... As mentioned, they are safer, but as long as my application in development (a telnet game) receives transmitted passwords as plain-text, there is a new challenge for me to solve that first. :-)

You should still use salt, even if it is bad salt. If you have few users, even appending a single site-specific string will help frustrate people with pre-generated tables. "openssl rand -base64 36" will produce something Lua-friendly; drop it into the source code if necessary for now.[1]

The reason is the period of vulnerability. An attacker must listen while a plaintext password is entered; if the attacker is limited to this they can only get passwords as people log in. However, if the attacker can obtain the hashed password file, they can attack the passwords of all your users immediately and offline. Probably some of your users have reused their password on other sites.

A bunch of MMO gold-selling game account cracks were probably traceable to this; people often use the same game username and password on a crappy PHP forum with unsalted passwords. Attackers only needed a PHP exploit to get read-only access to the account table once. They could then run the hashes through a rainbow table, and then log into the MMO and strip the character naked. No, there was not necessarily a plague of keyloggers in cheat software--just some web forums too lazy to salt passwords.[2]

The /usr/bin/openssl command can also be used to create and verify salted passwords (see "man 1ssl passwd") so if you can shell out you don't have to deal with any of this.

Plaintext authentication is bad, but it's bad in different ways. max(plaintext, unsalted) < bad <= (plaintext+unsalted).

Jay

[1]: Don't forget to fix your authentication code later. Once you become popular or paranoid, you can upgrade people to per-password salts gradually as they log in.

[2]: Plus PHP. I find it's generally safe to blame PHP for about anything, as it usually makes doing the correct/secure thing hard, and the wrong thing easy. Don't let this happen to your web framework.
Reply | Threaded
Open this post in threaded view
|

Re: Storing passwords

Paco Willers
Jay, that's great, thanks. I didn't realise the importance of the period of vulnerability, so I will use salt and improve my password verification before doing anything else.

I think it's a good idea to not only scramble the password, but to scramble a combination of username, password and user rights.

Today/night I learned a lot about cryptography and security.


Have a nice day,
Paco


2012/5/21 Jay Carlson <[hidden email]>
On May 21, 2012, at 4:19 PM, Paco Willers wrote:
>
> I now use http://www.keplerproject.org/md5/. The md5.sumhexa(message) function is what I was looking for. This library also contains several other functions which have my interest.
>
> About bcrypt and others... As mentioned, they are safer, but as long as my application in development (a telnet game) receives transmitted passwords as plain-text, there is a new challenge for me to solve that first. :-)

You should still use salt, even if it is bad salt. If you have few users, even appending a single site-specific string will help frustrate people with pre-generated tables. "openssl rand -base64 36" will produce something Lua-friendly; drop it into the source code if necessary for now.[1]

The reason is the period of vulnerability. An attacker must listen while a plaintext password is entered; if the attacker is limited to this they can only get passwords as people log in. However, if the attacker can obtain the hashed password file, they can attack the passwords of all your users immediately and offline. Probably some of your users have reused their password on other sites.

A bunch of MMO gold-selling game account cracks were probably traceable to this; people often use the same game username and password on a crappy PHP forum with unsalted passwords. Attackers only needed a PHP exploit to get read-only access to the account table once. They could then run the hashes through a rainbow table, and then log into the MMO and strip the character naked. No, there was not necessarily a plague of keyloggers in cheat software--just some web forums too lazy to salt passwords.[2]

The /usr/bin/openssl command can also be used to create and verify salted passwords (see "man 1ssl passwd") so if you can shell out you don't have to deal with any of this.

Plaintext authentication is bad, but it's bad in different ways. max(plaintext, unsalted) < bad <= (plaintext+unsalted).

Jay

[1]: Don't forget to fix your authentication code later. Once you become popular or paranoid, you can upgrade people to per-password salts gradually as they log in.

[2]: Plus PHP. I find it's generally safe to blame PHP for about anything, as it usually makes doing the correct/secure thing hard, and the wrong thing easy. Don't let this happen to your web framework.

Reply | Threaded
Open this post in threaded view
|

Re: Storing passwords

William Ahern
In reply to this post by Paco Willers
On Mon, May 21, 2012 at 10:19:53PM +0200, Paco Willers wrote:

> SOLVED!
>
> Thanks to all!
>
> I now use http://www.keplerproject.org/md5/. The md5.sumhexa(message)
> function is what I was looking for. This library also contains several
> other functions which have my interest.
>
> About bcrypt and others... As mentioned, they are safer, but as long as my
> application in development (a telnet game) receives transmitted passwords
> as plain-text, there is a new challenge for me to solve that first. :-)
>

If you insist on using bare MD5, you should at least use HMAC-MD5, using the
password as the secret key and the salt as the message. MD5 alone is
effectively broken for all cryptograhic uses.

It's one thing to be explicit about not providing a particular security
measure, in this case transport security (i.e. unencrypted tranmission).
It's quite another to implement a measure incorrectly. Using MD5 alone is
barely a step up from ROT13 at this point. At least with ROT13 there're no
illusions.

Reply | Threaded
Open this post in threaded view
|

Re: Storing passwords

steve donovan
In reply to this post by Tony Finch
On Mon, May 21, 2012 at 8:15 PM, Tony Finch <[hidden email]> wrote:
> No, don't use a bare hash for storing passwords. Use the standard crypt()
> function, or if you want to be even safer use bcrypt or scrypt.

If you're already using luaposix, then it has the standard crypt() available.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Storing passwords

Miles Bader-2
steve donovan <[hidden email]> writes:
>> No, don't use a bare hash for storing passwords. Use the standard
>> crypt() function, or if you want to be even safer use bcrypt or
>> scrypt.
>
> If you're already using luaposix, then it has the standard crypt()
> available.

... and if you're on a non-ancient version of linux (well, anything
using glibc), the standard crypt function supports sha-256 and sha-512
as well...

-miles

--
Innards, n. pl. The stomach, heart, soul, and other bowels.

Reply | Threaded
Open this post in threaded view
|

Is having lua_State per thread safe?

Tezduyar Lindskog, Umut
In reply to this post by Paco Willers

Hi,

 

I have 2 different threads and each thread is creating an instance of lua_State and only working with the one that it have created. Is there any part of the lua runtime that will not be thread safe even though they only work with their own lua_State?

 

I have looked at the symbols of the compiled lua library and there are no variables going into data or bss section. This makes me believe that it is safe to have each thread its own lua_State to work with but I would like to get your input.

 

Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: Is having lua_State per thread safe?

Erik Hougaard
On 22-05-2012 09:41, Tezduyar Lindskog, Umut wrote:

I have 2 different threads and each thread is creating an instance of lua_State and only working with the one that it have created. Is there any part of the lua runtime that will not be thread safe even though they only work with their own lua_State?

 

I have looked at the symbols of the compiled lua library and there are no variables going into data or bss section. This makes me believe that it is safe to have each thread its own lua_State to work with but I would like to get your input.


A lua_State is completly isolated, so they are thread safe. (Has been since Lua 4.0)

/Erik
Reply | Threaded
Open this post in threaded view
|

Re: Is having lua_State per thread safe?

Patrick Rapin
> A lua_State is completly isolated, so they are thread safe. (Has been since
> Lua 4.0)

Until Lua 5.0, the parser was not completely reentrant.
So it is more correct to say that a lua_State is fully thread safe
since Lua 5.1.

Reply | Threaded
Open this post in threaded view
|

RE: Is having lua_State per thread safe?

Tezduyar Lindskog, Umut
Erik, thank you for your answer.
Patrik, what I understand from "lua_State is fully thread safe" statement is more than one thread can work on the same lua_State simultaneously? Is this what you meant? If so, what are the synchronization primitives used by lua to support this feature?

Thanks.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Patrick Rapin
Sent: Tuesday, May 22, 2012 10:57 AM
To: Lua mailing list
Subject: Re: Is having lua_State per thread safe?

> A lua_State is completly isolated, so they are thread safe. (Has been since
> Lua 4.0)

Until Lua 5.0, the parser was not completely reentrant.
So it is more correct to say that a lua_State is fully thread safe
since Lua 5.1.


Reply | Threaded
Open this post in threaded view
|

Re: Is having lua_State per thread safe?

Roberto Ierusalimschy
In reply to this post by Patrick Rapin
> > A lua_State is completly isolated, so they are thread safe. (Has been since
> > Lua 4.0)
>
> Until Lua 5.0, the parser was not completely reentrant.
> So it is more correct to say that a lua_State is fully thread safe
> since Lua 5.1.

Reentrance in this case is not related to thread safety. The parser
in one state cannot be called while the parser in the same state is
working; the parser in a different state is completely unrelated.

Since Lua 4.0 Lua has multiple states, and different states do not share
any mutable data (even when parsing).

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Storing passwords

Jay Carlson
In reply to this post by William Ahern
On May 22, 2012, at 3:02 AM, William Ahern wrote:

> If you insist on using bare MD5, you should at least use HMAC-MD5, using the
> password as the secret key and the salt as the message.

This should be much better than concatenation.  See http://en.wikipedia.org/wiki/HMAC#Design_principles for the really short version.

> MD5 alone is
> effectively broken for all cryptograhic uses.

I think this is probably a bit strong for the reversibility case, although I would not use it for anything given a choice. The larger context is that, like string concatenation in SQL queries (see http://bobby-tables.com/ ), unsalted hashes have been involved in a lot of high-visibility Web attacks and people are trying to make them socially unacceptable. You can still implement salting poorly, and me not thinking HMAC is an example.

GI Joe[1] has good advice: "Math is hard--let's go shopping!" Let other people build your authentication mechanisms. If nothing else, you can blame them if it breaks. A modern Unix crypt() is not bad; although not obvious from some documentation, even the "md5" crypt is actually a thousand rounds.

I argue that designers who are aware of salt and the attack models it counters are more likely to remain afraid of the right things. But as you say, there is a temptation to leave a bad or incomplete implementation in place, especially if people think "hash" (or "salt") are magic. An example:

Apache Tomcat did not support salt in hashed password authentication until like 6.0 without source modification. One exception: the LDAP module had a special hack to interoperate with a particular LDAP server which stored salted passwords. So there was some awareness of this issue among committers, but this did not help.

Jay

[1]: http://en.wikipedia.org/wiki/Barbie_Liberation_Organization
12