[web2py:27680] Re: Default CRYPT() is unsecure

[Jonathan Lundell]

On Jul 30, 2009, at 11:47 PM, Jonathan Lundell wrote:

>
> On Jul 30, 2009, at 11:32 PM, Bottiger wrote:
>
>>
>>> Precomputing the possible hashes for each base password requires a
>>> table of 2^60 hashes *per password*. On the other hand, a hash of a
>> single deterministic transform of each password requires one hash per
>> password.
>>
>> I don't think you are understanding the situation, and I am getting a
>> bit tired of repeating myself.
>
> Well, that's up to you, of course.
>
>>
>> The problem with unsalted passwords is when the database is
>
> (did you mean "salted passwords"?)
>
>> compromised. When it is compromised, the salt becomes publicly
>> available, and having a totally random salt is not going to be a big
>> difference between a semi-random salt. To an attacker, this is what
>> they see:
>
> BTW, I haven't seen a proposal for semi-random salt, only for
> deterministic salt. I'm not actually sure what semi-random salt means.
>
>>
>> My suggestion: password + x characters recorded in the db (as the
>> password itself)
>> Your suggestion: password + x characters recorded in the db (in
>> another field)
>>
>> To crack these passwords they still only need to calculate password+x
>> characters stored in the db regardless of how random your salt is.  
>> The
>> only thing that really matters is that it is reasonably different for
>> each password, and that no one else has made a rainbow table for a
>> salt that you happened to choose.
>
> With a hash that's a deterministic function of the password (repeated,
> inverted, whatever), a dictionary table needs only one entry per
> plaintext original password. (How does the attacker know the function?
> Download web2py and read the code.) Precompute one table and you've
> broken *every password* in your dictionary. (It's no help against
> truly strong passwords, but what we're trying to do here is to protect
> middling passwords.) And you don't need access to the file of password
> hashes.

Check that. You do need access, but given access you need to do  
essentially zero work to crack all the passwords in your precomputed  
dictionary.

>
> With random salt, on the other hand, even with access to the salted
> hash, you have to do that much work to crack just one not-so-strong
> password.
>
> The point of rainbow tables is to amortize the computation across the
> entire password dictionary (with a bonus of not needing to see the
> actual hashes). The point of salted hashes is to require the attacker
> to use the same amount of computation to attack a single password, and
> that only if he has accessed to the salted hash.
>
> Night and day.
>
>
>>
>>
>> On Jul 30, 10:50 pm, Jonathan Lundell  wrote:
>>> On Jul 30, 2009, at 10:26 PM, Bottiger wrote:
>>>
>>>
>>>
>>>
>>>
> That may not be a good idea, I think. That makes your password
> longer but with a possible cryptographic weakness because it's
> following a known generation rule (being formed by a string
> repeated 3 times).
>>>
 The primary concern is a precomputed rainbow hash table.
>>>
 Anything related to password generation strength depends on the
 person's original password and even a random salt does not help,
 because if the database is compromised, then the attack knows which
 salt to generate hashes for. Therefore there really isn't anything
 wrong with just doubling or tripling the password as a salt.
>>>
 In fact, many websites such as Reddit (which I examined the source
 code) does this.
>>>
>>> Still a bad idea.
>>>
>>> A rainbow table is basically a precomputed dictionary attack. The
>>> size
>>> of the dictionary is a function of the number of distinct passwords
>>> that we're trying to guess. Dictionary attacks work for short
>>> passwords, but are impractical against longer passwords. A password
>>> using letters, numbers and a few special characters carries in  
>>> excess
>>> of 6 bits of information per character. 10 bytes of password plus 10
>>> bytes of random salt gives us 120 bits total, for a dictionary space
>>> of 2^120 hashes.
>>>
>>> Precomputing the possible hashes for each base password requires a
>>> table of 2^60 hashes *per password*. On the other hand, a hash of a
>>> single deterministic transform of each password requires one hash  
>>> per
>>> password.
>>>
>>> That's the point of salt.
>>>
>>> And no, I'm not concerned about spending a few extra bytes per
>>> password. I just paid $90 for a terabyte drive; that'll store plenty
>>> of password hashes, even if we "waste" a few bytes each making them
>>> more secure.
>>>
>>>
>>>
 On Jul 30, 9:51 pm, Francisco Gama  wrote:
> On Jul 31, 5:16 am, Bottiger  wrote:
>>>
>> As long as the salt is different for every password, it pretty
>> much
>> makes it infeasible for someone to create a large enough rainbow
>> hash
>> table attack.
>>>
>> The Unix salt of 12 random bytes is ok, but comes at the cost of
>> extra
>> storage an

[web2py:27681] Re: 'SQLField' object has no attribute 'store'

[annet]

Massimo,

> It looks to me you have a new version of globals.py but an old version
> of sql.py. Is this possible?

Yes, after upgrading to version 1.65.7 the upload field worked.


Kind regards,

Annet.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27682] Re: executing a sql script

[max]

thanks for the answer massimo.

xml parsing  i have done with dom parser.

for me the difficult part is to how i intgrate my xml parsing program
to the files which i have uploaded throgh web2py.
I want it  this way.

1. Upload the xml file and a zip file
   implemented with web2py
2. parse the content from the xml file and insert the data into a
mysql databse
i can generate the sql insert statesments with my xml parser.
interesting in knowing how i can insert this commands on the fly.
3. copy the content of the zip file to a specific folder other than
upload folder
have  written a simple file copy mechanism,  how can i execute this
script using web2py




On 30 Jul., 17:49, mdipierro  wrote:
> Is you problem parsing the xml data?
> I am not expert but Python comes with this 
> parser:http://docs.python.org/library/xml.sax.html
>
> massimo
>
> On Jul 30, 8:49 am, max  wrote:
>
> > I am trying to execute  upload a xml parser into my application and
> > parse it on the fly and insert the data into a database which is
> > connected to the web2py.
> > I have already written  a program to upload the xml file and the
> > files  (which are desribed in the xml)  seperately.
> > Can somebody give me some idea how this is done using web2py?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27683] Re: Default CRYPT() is unsecure

[Bottiger]

>If the attacker knows (by reading the web2py source) that you're, say,
>concatenating the base password three times, then he knows that you
>haven't increased the password space by even one entry: there's a 1:1
>mapping between base passwords and transformed passwords.

So far you have kept on ignoring the gist of the problem. If the
attacker has access to the salt, it doesn't matter whether or not you
know the relationship between the password and the salt because you
already know the salt. The attacker could not care less about whether
you used a random number generator or a function related to the
password.

> If the attacker knows (by reading the web2py source) that you're, say,
> concatenating the base password three times, then he knows that you
> haven't increased the password space by even one entry: there's a 1:1
> mapping between base passwords and transformed passwords.

Can you please actually take some time to understand my previous
comments? You could use a random 100 byte salt, and it
wouldn't increase your password space for that password. All the
attacker needs to do is this:

for candidate in permutations(alphanumeric_and_symbols):
  if md5(candidate+salt) == hash: return candidate

This is the same brute force method that would be used when you have a
completely random salt or a salt based on the password itself. Again I
repeat, the attacker could not care less about whether you used a
random number generator or a function related to the password.

On Jul 30, 11:52 pm, Jonathan Lundell  wrote:
> On Jul 30, 2009, at 11:43 PM, Bottiger wrote:
>
>
>
> >> Dictionary attacks work for short
> >> passwords, but are impractical against longer passwords. A password
> >> using letters, numbers and a few special characters carries in excess
> >> of 6 bits of information per character. 10 bytes of password plus 10
> >> bytes of random salt gives us 120 bits total, for a dictionary space
> >> of 2^120 hashes.
>
> >> On the other hand, a hash of a
> >> single deterministic transform of each password requires one hash per
> >> password.
>
> > This entire argument is wrong because the salt is in plaintext and
> > available to the attacker when the DB is compromised. You are not
> > increasing the search space when you add a salt in a rainbow hash
> > attack because the attacker already knows the salt. If you want to
> > make the search space larger, you need to increase the size of the
> > password **prior** to hashing, not after it is hashed.
>
> Better passwords are more secure, yes.
>
> Making a password bigger by means of a deterministic transform of a  
> short password is of no help whatsoever (unless you keep the transform  
> a secret, of course, but nobody is proposing that).
>
> If the attacker knows (by reading the web2py source) that you're, say,  
> concatenating the base password three times, then he knows that you  
> haven't increased the password space by even one entry: there's a 1:1  
> mapping between base passwords and transformed passwords.
>
> That's the problem.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27684] Re: Default CRYPT() is unsecure

[Fran]

On Jul 31, 4:10 am, mdipierro  wrote:
> We cannot break backward compatibility. People should specify a key
> and use the HMAC+SHA512 anyway.

Currently the default auth_user table just has:
table[passfield].requires = [CRYPT()]

So *all* instances should amend that, right?

This should be in the scaffolding app & very clear in the docs:
http://web2py.com/examples/default/tools#authentication
new manual (chapter 8)

F
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27685] Re: 'SQLField' object has no attribute 'store'

[annet]

Massimo,

> It looks to me you have a new version of globals.py but an old version
> of sql.py. Is this possible?

Yes, upgrading to version 1.65.7 solved the problem.


But now I am facing the following problem:

In my model I defined the following table:

db.define_table('level',
db.Field('level',length=36,default='',notnull=True,unique=True),
db.Field('image',type='upload'),
migrate='level.table')
db.level.level.requires=[IS_LENGTH(36,error_message='lengte
overschreidt 36 tekens'),IS_NOT_EMPTY(),IS_NOT_IN_DB
(db,'level.level',error_message='level niet uniek')]
db.level.level.label='Level * '
db.level.image.autodelete=True


In my controller I got the following function:

def timetable():
...
timetable=db((db.lesrooster.bedrijf==company_id)&
(db.lesrooster.dag==db.dag.id)&(db.lesrooster.level==db.level.id))\
.select
(db.lesrooster.ALL,db.dag.dag,db.level.image,orderby=db.lesrooster.dag|
db.lesrooster.tijd)
...
return dict(..., timetable=timetable, ...)


... and in my view:

...

  {{=activiteit.level.image}}

...


The problem is, that when I expose the function instead of the image
the file name:
level.image.aef56e3f826179e6.677265656e5f646f742e706e67.png is being
displayed. Why is that?


Kind regards,

Annet.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27686] Re: Default CRYPT() is unsecure

[Bottiger]

We can probably make a validator called CRYPT2() so we don't have to
break backward compatibility. In my opinion though, this is a rather
insecure default for a framework that bills itself as being very
secure. I have seen many hacklogs where PHP frameworks were often
compromised by sql injection -> unsalted md5 dump -> rainbow lookup ->
attacker now accesses the entire server because the host used the same
password on his website as the root account.

I think SHA512 with a static key would be ok, as I have yet to see any
rainbow tables for that yet. But theoretically, having a different
salt for each password would prevent any attackers from generating 1
table for all the passwords from a static salt.

And with my method you wouldn't have to allocate additional storage to
get the same effect.

On Jul 31, 12:19 am, Fran  wrote:
> On Jul 31, 4:10 am, mdipierro  wrote:
>
> > We cannot break backward compatibility. People should specify a key
> > and use the HMAC+SHA512 anyway.
>
> Currently the default auth_user table just has:
> table[passfield].requires = [CRYPT()]
>
> So *all* instances should amend that, right?
>
> This should be in the scaffolding app & very clear in the 
> docs:http://web2py.com/examples/default/tools#authentication
> new manual (chapter 8)
>
> F
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27687] Re: Default CRYPT() is unsecure

[Jonathan Lundell]

On Jul 31, 2009, at 12:16 AM, Bottiger wrote:

>> If the attacker knows (by reading the web2py source) that you're,  
>> say,
>> concatenating the base password three times, then he knows that you
>> haven't increased the password space by even one entry: there's a 1:1
>> mapping between base passwords and transformed passwords.
>
> So far you have kept on ignoring the gist of the problem. If the
> attacker has access to the salt, it doesn't matter whether or not you
> know the relationship between the password and the salt because you
> already know the salt. The attacker could not care less about whether
> you used a random number generator or a function related to the
> password.
>
>> If the attacker knows (by reading the web2py source) that you're,  
>> say,
>> concatenating the base password three times, then he knows that you
>> haven't increased the password space by even one entry: there's a 1:1
>> mapping between base passwords and transformed passwords.
>
> Can you please actually take some time to understand my previous
> comments? You could use a random 100 byte salt, and it
> wouldn't increase your password space for that password. All the
> attacker needs to do is this:
>
> for candidate in permutations(alphanumeric_and_symbols):
>  if md5(candidate+salt) == hash: return candidate
>
> This is the same brute force method that would be used when you have a
> completely random salt or a salt based on the password itself. Again I
> repeat, the attacker could not care less about whether you used a
> random number generator or a function related to the password.

The difference is that with a deterministic transform of the password  
(this includes static salt, or salt that's a function of the base  
password), the attacker performs your loop once and solves every  
password in his list. And the loop result can be precomputed into a  
rainbow table.

With random salt, the attacker must perform the loop (and it's a long  
loop) once for every hash he wants to attack. And the loop result  
cannot (practically) be precomputed.

OK? Deterministic transform means that one pass through the loop,  
precomputed, breaks all passwords in the permutation dictionary.

Random salt means that one pass through the loop breaks *one* password  
*if* it's in the permutation dictionary. And it can't be precomputed.

Again, it's no substitute for a strong password. But it helps.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27688] Can I use HTTP PUT method?

[诚子]

Hi, I wan't use PUT method and DELETE method,to build a RESTful
service,how to get an PUT method and DELETE data?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27689] Re: Default CRYPT() is unsecure

[Bottiger]

Again, you haven't taken the time to understand what I have said.

What you've been complaining about is only valid if you use the same
salt for every password.

Having a salt be a function of the password is not the same thing as
having the same salt for every password.

On Jul 31, 12:31 am, Jonathan Lundell  wrote:
> On Jul 31, 2009, at 12:16 AM, Bottiger wrote:
>
>
>
> >> If the attacker knows (by reading the web2py source) that you're,  
> >> say,
> >> concatenating the base password three times, then he knows that you
> >> haven't increased the password space by even one entry: there's a 1:1
> >> mapping between base passwords and transformed passwords.
>
> > So far you have kept on ignoring the gist of the problem. If the
> > attacker has access to the salt, it doesn't matter whether or not you
> > know the relationship between the password and the salt because you
> > already know the salt. The attacker could not care less about whether
> > you used a random number generator or a function related to the
> > password.
>
> >> If the attacker knows (by reading the web2py source) that you're,  
> >> say,
> >> concatenating the base password three times, then he knows that you
> >> haven't increased the password space by even one entry: there's a 1:1
> >> mapping between base passwords and transformed passwords.
>
> > Can you please actually take some time to understand my previous
> > comments? You could use a random 100 byte salt, and it
> > wouldn't increase your password space for that password. All the
> > attacker needs to do is this:
>
> > for candidate in permutations(alphanumeric_and_symbols):
> >  if md5(candidate+salt) == hash: return candidate
>
> > This is the same brute force method that would be used when you have a
> > completely random salt or a salt based on the password itself. Again I
> > repeat, the attacker could not care less about whether you used a
> > random number generator or a function related to the password.
>
> The difference is that with a deterministic transform of the password  
> (this includes static salt, or salt that's a function of the base  
> password), the attacker performs your loop once and solves every  
> password in his list. And the loop result can be precomputed into a  
> rainbow table.
>
> With random salt, the attacker must perform the loop (and it's a long  
> loop) once for every hash he wants to attack. And the loop result  
> cannot (practically) be precomputed.
>
> OK? Deterministic transform means that one pass through the loop,  
> precomputed, breaks all passwords in the permutation dictionary.
>
> Random salt means that one pass through the loop breaks *one* password  
> *if* it's in the permutation dictionary. And it can't be precomputed.
>
> Again, it's no substitute for a strong password. But it helps.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27690] Re: executing a sql script

[Fran]

On Jul 31, 8:09 am, max  wrote:
> for me the difficult part is to how i intgrate my xml parsing program
> to the files which i have uploaded throgh web2py.
> I want it  this way.
> 1. Upload the xml file and a zip file
>    implemented with web2py
> 2. parse the content from the xml file and insert the data into a
> mysql databse
> i can generate the sql insert statesments with my xml parser.
> interesting in knowing how i can insert this commands on the fly.
> 3. copy the content of the zip file to a specific folder other than
> upload folder
> have  written a simple file copy mechanism,  how can i execute this
> script using web2py

Can this be done via an onvalidation callback?
onvalidation = lambda form: myParser(form)
form = crud.create(db.table_with_uploadfield,
onvalidation=onvalidation)

I'm interested in ensuring this works as I'll need it to be able to
handle KMZ files & KML with Network Links inside...so pls feedback on
whether onvalidation works as-is or whether upload fields need special
handling...

F
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27691] Re: Default CRYPT() is unsecure

[Yarko Tymciurak]

On Fri, Jul 31, 2009 at 2:31 AM, Jonathan Lundell wrote:

>
> On Jul 31, 2009, at 12:16 AM, Bottiger wrote:
>
> .

> The difference is that with a deterministic transform of the password
> (this includes static salt, or salt that's a function of the base
> password), the attacker performs your loop once and solves every
> password in his list. And the loop result can be precomputed into a
> rainbow table.


How do you figure?  If the salt is different, and is based on the "solution"
of the hash,
then how does having an algorithm to extract the salt help?  You cannot use
the last
salt to help;  you have to solve the next hash to get it's value (you can
check it after).

Am I missing something?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27692] Re: Default CRYPT() is unsecure

[Bottiger]

Ah, someone here finally understands me.

On Jul 31, 12:38 am, Yarko Tymciurak  wrote:
> On Fri, Jul 31, 2009 at 2:31 AM, Jonathan Lundell wrote:
>
>
>
> > On Jul 31, 2009, at 12:16 AM, Bottiger wrote:
>
> > .
> > The difference is that with a deterministic transform of the password
> > (this includes static salt, or salt that's a function of the base
> > password), the attacker performs your loop once and solves every
> > password in his list. And the loop result can be precomputed into a
> > rainbow table.
>
> How do you figure?  If the salt is different, and is based on the "solution"
> of the hash,
> then how does having an algorithm to extract the salt help?  You cannot use
> the last
> salt to help;  you have to solve the next hash to get it's value (you can
> check it after).
>
> Am I missing something?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27694] Re: Default CRYPT() is unsecure

[Jonathan Lundell]

On Jul 31, 2009, at 12:19 AM, Fran wrote:

> On Jul 31, 4:10 am, mdipierro  wrote:
>> We cannot break backward compatibility. People should specify a key
>> and use the HMAC+SHA512 anyway.
>
> Currently the default auth_user table just has:
> table[passfield].requires = [CRYPT()]
>
> So *all* instances should amend that, right?
>
> This should be in the scaffolding app & very clear in the docs:
> http://web2py.com/examples/default/tools#authentication
> new manual (chapter 8)

It wouldn't be extraordinarily difficult to migrate an existing MD5- 
hashed password table to a stronger method.

Suppose we could specify two hash functions, CRYPT() and  
STRONGCRYPT(). When validating a password, we try both, but when  
hashing a new password we always use STRONGCRYPT(). If we validate an  
entered password with CRYPT(), then we update it immediately with  
STRONGCRYPT(), which we can do because we have the (validated)  
plaintext password.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27695] Re: Default CRYPT() is unsecure

[Jonathan Lundell]

On Jul 31, 2009, at 12:38 AM, Yarko Tymciurak wrote:

> On Fri, Jul 31, 2009 at 2:31 AM, Jonathan Lundell  
>  wrote:
>
> On Jul 31, 2009, at 12:16 AM, Bottiger wrote:
>
> .
> The difference is that with a deterministic transform of the password
> (this includes static salt, or salt that's a function of the base
> password), the attacker performs your loop once and solves every
> password in his list. And the loop result can be precomputed into a
> rainbow table.
>
> How do you figure?  If the salt is different, and is based on the  
> "solution" of the hash,
> then how does having an algorithm to extract the salt help?  You  
> cannot use the last
> salt to help;  you have to solve the next hash to get it's value  
> (you can check it after).
>
> Am I missing something?

Give me a specific example of the salted hash function you'd use for  
this mechanism, please.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27693] Re: Default CRYPT() is unsecure

[Jonathan Lundell]

On Jul 31, 2009, at 12:35 AM, Bottiger wrote:

>
> Again, you haven't taken the time to understand what I have said.
>
> What you've been complaining about is only valid if you use the same
> salt for every password.
>
> Having a salt be a function of the password is not the same thing as
> having the same salt for every password.

For all practical purposes, it is the same. The underlying problem is  
that there's a 1:1 correspondence between the base password and the  
salted password, so that only one rainbow table need be precomputed.

>
> On Jul 31, 12:31 am, Jonathan Lundell  wrote:
>> On Jul 31, 2009, at 12:16 AM, Bottiger wrote:
>>
>>
>>
 If the attacker knows (by reading the web2py source) that you're,
 say,
 concatenating the base password three times, then he knows that you
 haven't increased the password space by even one entry: there's a  
 1:1
 mapping between base passwords and transformed passwords.
>>
>>> So far you have kept on ignoring the gist of the problem. If the
>>> attacker has access to the salt, it doesn't matter whether or not  
>>> you
>>> know the relationship between the password and the salt because you
>>> already know the salt. The attacker could not care less about  
>>> whether
>>> you used a random number generator or a function related to the
>>> password.
>>
 If the attacker knows (by reading the web2py source) that you're,
 say,
 concatenating the base password three times, then he knows that you
 haven't increased the password space by even one entry: there's a  
 1:1
 mapping between base passwords and transformed passwords.
>>
>>> Can you please actually take some time to understand my previous
>>> comments? You could use a random 100 byte salt, and it
>>> wouldn't increase your password space for that password. All the
>>> attacker needs to do is this:
>>
>>> for candidate in permutations(alphanumeric_and_symbols):
>>>  if md5(candidate+salt) == hash: return candidate
>>
>>> This is the same brute force method that would be used when you  
>>> have a
>>> completely random salt or a salt based on the password itself.  
>>> Again I
>>> repeat, the attacker could not care less about whether you used a
>>> random number generator or a function related to the password.
>>
>> The difference is that with a deterministic transform of the password
>> (this includes static salt, or salt that's a function of the base
>> password), the attacker performs your loop once and solves every
>> password in his list. And the loop result can be precomputed into a
>> rainbow table.
>>
>> With random salt, the attacker must perform the loop (and it's a long
>> loop) once for every hash he wants to attack. And the loop result
>> cannot (practically) be precomputed.
>>
>> OK? Deterministic transform means that one pass through the loop,
>> precomputed, breaks all passwords in the permutation dictionary.
>>
>> Random salt means that one pass through the loop breaks *one*  
>> password
>> *if* it's in the permutation dictionary. And it can't be precomputed.
>>
>> Again, it's no substitute for a strong password. But it helps.
> >



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27696] Re: Default CRYPT() is unsecure

[Jonathan Lundell]

On Jul 31, 2009, at 12:48 AM, Jonathan Lundell wrote:

> On Jul 31, 2009, at 12:38 AM, Yarko Tymciurak wrote:
>
>> On Fri, Jul 31, 2009 at 2:31 AM, Jonathan Lundell  
>>  wrote:
>>
>> On Jul 31, 2009, at 12:16 AM, Bottiger wrote:
>>
>> .
>> The difference is that with a deterministic transform of the password
>> (this includes static salt, or salt that's a function of the base
>> password), the attacker performs your loop once and solves every
>> password in his list. And the loop result can be precomputed into a
>> rainbow table.
>>
>> How do you figure?  If the salt is different, and is based on the  
>> "solution" of the hash,
>> then how does having an algorithm to extract the salt help?  You  
>> cannot use the last
>> salt to help;  you have to solve the next hash to get it's value  
>> (you can check it after).
>>
>> Am I missing something?
>
> Give me a specific example of the salted hash function you'd use for  
> this mechanism, please.
>

...and let me set some context.

The default CRYPT() right now is md5(password).

Bottinger's proposal that I originally objected to was:

md5(password+password[-1])

He later suggested that "you could double or triple the original  
password before putting it through the hash", so

md5(password+password)

or  md5(password*3)


Suppose you have a dictionary of 1,000,000 weak passwords and  
precompute their 1,000,000 hashes.

Now suppose you want to attack md5(password+password). How many hashes  
do you need to precompute? 1,000,000.


I'm suggesting (sticking with md5 for comparability):

md5(password+random)+random

...where random is randomly chosen for each new password.


You're suggesting?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27697] Re: Default CRYPT() is unsecure

[Bottiger]

Can you please take some time to actually understand the situation.
Every time you keep repeating the same factually incorrect statements.

md5(password1+password1)

password1 is not the same as

md5(password2+password2)

> Suppose you have a dictionary of 1,000,000 weak passwords and  precompute 
> their 1,000,000 hashes. How many hashes do you need to precompute? 1,000,000.

Is there a point in there somewhere? Your suggestion:

md5(password+random)+random (BTW systems use md5(password+random), the
extra random is useless)

The attacker knows what random is. It is not random anymore. This is
what the attacker sees:

md5(password+characters_in_db)+characters_in_db

Suppose you have a dictionary of 1,000,000 weak passwords and
precompute their 1,000,000 hashes. How many hashes do you need to
precompute with your idea? 1,000,000. There is no difference.

And this is the last thing I will say about this matter.

On Jul 31, 1:19 am, Jonathan Lundell  wrote:
> On Jul 31, 2009, at 12:48 AM, Jonathan Lundell wrote:
>
>
>
> > On Jul 31, 2009, at 12:38 AM, Yarko Tymciurak wrote:
>
> >> On Fri, Jul 31, 2009 at 2:31 AM, Jonathan Lundell  
> >>  wrote:
>
> >> On Jul 31, 2009, at 12:16 AM, Bottiger wrote:
>
> >> .
> >> The difference is that with a deterministic transform of the password
> >> (this includes static salt, or salt that's a function of the base
> >> password), the attacker performs your loop once and solves every
> >> password in his list. And the loop result can be precomputed into a
> >> rainbow table.
>
> >> How do you figure?  If the salt is different, and is based on the  
> >> "solution" of the hash,
> >> then how does having an algorithm to extract the salt help?  You  
> >> cannot use the last
> >> salt to help;  you have to solve the next hash to get it's value  
> >> (you can check it after).
>
> >> Am I missing something?
>
> > Give me a specific example of the salted hash function you'd use for  
> > this mechanism, please.
>
> ...and let me set some context.
>
> The default CRYPT() right now is md5(password).
>
> Bottinger's proposal that I originally objected to was:
>
>         md5(password+password[-1])
>
> He later suggested that "you could double or triple the original  
> password before putting it through the hash", so
>
>         md5(password+password)
>
> or      md5(password*3)
>
> Suppose you have a dictionary of 1,000,000 weak passwords and  
> precompute their 1,000,000 hashes.
>
> Now suppose you want to attack md5(password+password). How many hashes  
> do you need to precompute? 1,000,000.
>
> I'm suggesting (sticking with md5 for comparability):
>
>         md5(password+random)+random
>
> ...where random is randomly chosen for each new password.
>
> You're suggesting?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27698] Re: Default CRYPT() is unsecure

[Fran]

On Jul 31, 8:45 am, Jonathan Lundell  wrote:
> It wouldn't be extraordinarily difficult to migrate an existing MD5-
> hashed password table to a stronger method.

I really think that we need to be 'secure by default' - this is what
is claimed for the framework.
Even with clear documentation (& scaffolding) saying that developers
should add a line to their app to change table[passfield].requires,
this is bound to trip people up.

If this approach can be generalised into the default install of Web2Py
so that new installs are secure-by-default but old installs don't
break when upgraded, that would be really awesome :)

F
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27699] Re: 'SQLField' object has no attribute 'store'

[Fran]

On Jul 31, 8:23 am, annet  wrote:
>   {{=activiteit.level.image}}

> the file name:
> level.image.aef56e3f826179e6.677265656e5f646f742e706e67.png is being
> displayed. Why is that?

because that is what is stored in the DB.

To display the image you need something like:




F

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27700] Re: Help! URL rewrite using apache mod_rewrite

[Philip Kilner]

Hi,

LB22 wrote:
> OK, I don't know how but I missed Philip's post earlier:
> 
> "Is the rewrite rule within a virtual host block?"
> 
> This was exactly the problem - where I was trying Fran's suggestion
> for my mod_rewrite issues, I had added a rewrite rule to a virtual
> hosts block in httpd.conf, but forgotten to remove it.
> 
> Everything is now working as expected. Thanks again for all the help.
> Whenever I'm stuck, there are always people here to get me unstuck :o)
> 

Good stuff - glad you found it.

Plus, I now feel slightly less daft knowing it's not only me that has
made that mistake!

:-)


-- 

Regards,

PhilK

Email: p...@xfr.co.uk

'a bell is a cup...until it is struck'

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27701] Re: file downloading problem

[陶艺夫]

Thank you for reply.
I've been googling the right version of mod_wsgi for couples of hours and I
got nothing. I'll try to compile it form the source code. I'm under windows
xp [ :( ], python 2.5.4,apache 2.2.11.
How can I compile it?  Any instructions will be thankful.

2009/7/31 Yarko Tymciurak 

> I believe this is a cherrypy issue;  Can you use apache + mod_wsgi
> instead?  This is more reliable for serious work.
>
>
> On Thu, Jul 30, 2009 at 10:32 PM, 陶艺夫  wrote:
>
>> Hi,
>> I'm using "response.stream(file_name)" method to offer users downloading
>> files which are sort of business-classified, but the downloading process
>> always terminated halfway. The testing file is 4.2M, an Excel workbook.
>> Is there anything I can do with system configuration(CherryPy), or  it's
>> just an internet problem?
>>
>> thanks
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27702] Re: Auth. Customisation form created by register()

[Carl]

hi Fran,

I've figured it out.

In my view I've added
{{if form.errors and form.errors.password_two:}}Password fields don't match{{pass}}

at the end of my "Verify password" td.

thanks for your help.

Carl

On Jul 30, 12:48 pm, Carl  wrote:
> hi Fran,
>
> Have looked at {{=form.custom.begin}} and it looks just the ticket. It
> enables me to have one User table (which I've modified in db.py with
> additional fields) and then have two views: one for each type of user.
>
> I've one last sticking point...
>
> Now I'm no longer using {{=form}} I don't get the Password2 field
> added for free nor its data validation (that password == password2).
>
> And the thought occurs that if I wanted to have recaptcha I'd run into
> similar issues.
>
> Do you know if/how I can add password2 handling into my custom form
> view? (and recaptcha if I wanted that too?)
>
> Many thanks for your time
>
> Carl
>
> On Jul 29, 8:53 pm, Fran  wrote:
>
>
>
> > On Jul 29, 8:13 pm, Carl  wrote:
>
> > > for the future: being able to set my own form for register() would be
> > > real nice. at present I can do that only if I want to pull in a remote
> > > authentication system.
>
> > You can have extra fields on the register() form very easily - the
> > form is simply a SQLFORM of the auth_user table...so just create a
> > custom auth_user table with the fields you want before you call
> > auth.define_tables()
>
> > You can also make a full custom form in the usual way:
> > In the view instead of {{=form}} you can do:
> > {{=form.custom.begin}}
> > {{=form.custom.widget.first_name}}
> > etc
> > {{=form.custom.submit}}
> > {{=form.custom.end}}
>
> > & surround these elements with whatever HTML you want...
>
> > As long as the mandatory fields are populated then you're good to
> > go :)
>
> > F
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27703] Re: Auth. Customisation form created by register()

[Fran]

On Jul 31, 1:53 pm, Carl  wrote:
> I've figured it out.

Great - so much better when you solve it yourself :)

Thanks for sharing the trick...

F
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27704] Re: Converting a Django Tutorial to web2py

[A. C. Censi]

Some observations about the Django approach versus SQL are presented here:

http://slott-softwarearchitect.blogspot.com/2009/07/object-models-and-relational-joins.html
Object Models and Relational Joins -- Endless Confusion

Perhaps it could be of interest to show Web2py approach in the same way.

ACC

On Thu, Jul 30, 2009 at 1:16 AM, Yarko Tymciurak wrote:
> As Massimo pointed out, the philosophy and approach w/in django & web2py is
> different.
.
>> > > > On Jul 29, 7:11 pm, mdipierro  wrote:
>> >
>> > > > > These are good questions. web2py does not have something like
>> > > > > Django
>> > > > > managers and you have to achieve the same goal differently. This
>> > > > > is
>> > > > > because of different in design philosophy.
>> >
>> > > > > Django has an ORM, web2py has a DAL. In Django a model maps a
>> > > > > table


-- 
A. C. Censi
accensi [em] gmail [ponto] com
accensi [em] montreal [ponto] com [ponto] br

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27705] Re: Default CRYPT() is unsecure

[Jonathan Lundell]

On Jul 31, 2009, at 1:32 AM, Bottiger wrote:

> Can you please take some time to actually understand the situation.
> Every time you keep repeating the same factually incorrect statements.
>
> md5(password1+password1)
>
> password1 is not the same as
>
> md5(password2+password2)
>
>> Suppose you have a dictionary of 1,000,000 weak passwords and   
>> precompute their 1,000,000 hashes. How many hashes do you need to  
>> precompute? 1,000,000.
>
> Is there a point in there somewhere? Your suggestion:
>
> md5(password+random)+random (BTW systems use md5(password+random), the
> extra random is useless)
>
> The attacker knows what random is. It is not random anymore. This is
> what the attacker sees:
>
> md5(password+characters_in_db)+characters_in_db
>
> Suppose you have a dictionary of 1,000,000 weak passwords and
> precompute their 1,000,000 hashes. How many hashes do you need to
> precompute with your idea? 1,000,000. There is no difference.

1,000,000 * (size of random space)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27706] Re: silly question: embedding flash files in views

[carlo]

thank you all for replying.
It is definitely not a matter of syntax but of my poor knowledge of
Flash I suppose.
I found no way to get my mp4 imported in Flash converted in a "valid"
swf for playing: the proof of my wrong approach is the dimension of
the swf file obtained from Flash: 60KB against 6MB of the original mp4
file.
Maybe I will learn to use Flash the right way one day..

As soon as I used another tool to convert my mp4 video into swf (into
flv actually as you can read below) everything was ok and my original
syntax worked.

At present I chose to use the SWFObject approach which, among other
things, lets you play your movies as flv files and customized player
(I used the classic JW player), but even the classic  tag is
fine.

For the curious this is the code:



var flashvars = {};
flashvars.file = 
"{{=URL(r=request,c='static',f='xcel2xml.flv')}}";
var params = {};
params.play = "false";
params.loop = "false";
params.menu = "true";
params.quality = "best";
params.scale = "showall";
params.wmode = "window";
params.swliveconnect = "true";
params.allowfullscreen = "true";
params.allowscriptaccess = "always";
params.allownetworking = "all";
var attributes = {};
attributes.id = "container";

swfobject.embedSWF("{{=URL(r=request,c='static',f='player.swf')}}",
"myAlternativeContent", "640", "480", "9.0.0", false, flashvars,
params, attributes);


where player.swf= the JW Flash player and xcel2xml.flv=my video

In the body section of your view just put (shown only if the user does
not have Flash player installed):


http://www.adobe.com/go/getflashplayer";>
http://www.adobe.com/images/shared/download_buttons/
get_flash_player.gif" alt="Get Adobe Flash player" />



Everything about swfobject at http://code.google.com/p/swfobject/

carlo


On 31 Lug, 02:31, Jonathan Lundell  wrote:
> On Jul 30, 2009, at 5:21 PM, Miguel Lopes wrote:
>
>
>
>
>
> > On Thu, Jul 30, 2009 at 4:58 PM, Jonathan  
> > Lundell wrote:
>
> >> On Jul 30, 2009, at 7:47 AM, Jonathan Lundell wrote:
>
> >>> On Jul 30, 2009, at 7:42 AM, Miguel Lopes wrote:
>
>  If its in swf, it should work.
>
>  Although, I notice an error in the original snippet you posted
>  (besides the missing ' ):
>  {{url=URL(r=request,c='static',f='somefilename.swf)}}
>
>  Should be):
>  url={{URL(r=request,c='static',f='somefilename.swf')}}
>
> >>> Or maybe:
>
> >>> url={{=URL(r=request,c='static',f='somefilename.swf')}}
>
> >> Never mind. I see from a later post that the {{url=...}} was correct.
>
> > Forgive me. Actually I meant:
> > href="{{=URL(r=request,c='static',f='somefilename.swf')}}"
>
> > it is also true that:
> > {{url=URL(r=request,c='static',f='somefilename.swf')}}
>
> > is also correct. But the only thing it does is assign the url to a
> > variable, that is only available in the template. So if you are using
> > this to populate a href tag (like I assumed), you'll get an empty tag.
>
> What I meant was that Carlo's original question had this code:
>
> {{url=URL(r=request, c='static', f='somefilename.swf' )}}
> 
> 
> 
> 
> 
>
> ...where the treatment of url look fine to me.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27707] Re: Default CRYPT() is unsecure

[Julio]

.. And even if you use the same salt for each password It'd still be a
time-consuming job since for each "clear" password in a rainbow table
you'd have to "recompute" the new hash based on the salt and scan the
rainbow table entirely for each record, now I totally agree that
adding a salt for each password (obviously it has to be predictable so
we can generate the hash again at log in time) will strengthen the
passwords greatly.

My suggestion is simply implement the new salting algorithm, move the
unsalted hashed password to a lookup table (which will be deleted
eventually), and "expire" the passwords for all your users, and on the
next logon, they will have to type the old one, then create a new one
and this time it'll be hashed with the proper salt, this way, even
though "compatibility" will break, we'll still have a means to
"correct" this.

The way I do it in pyforum for instance, is this:

passwd = "Hello World"
hashed_pwd_tmp = hashlib.md5(passwd).hexdigest()
hashed_passwd = hashlib.md5("%s%s" % (tmp_hashed_pwd,
passwd)).hexdigest()

So basically I prepend (or append, I don't have the code at this time)
the hashed password to the clear password and re-hash the whole string
again, breakable? of course, but exponentially harder.

Julio

On Jul 31, 12:35 am, Bottiger  wrote:
> Again, you haven't taken the time to understand what I have said.
>
> What you've been complaining about is only valid if you use the same
> salt for every password.
>
> Having a salt be a function of the password is not the same thing as
> having the same salt for every password.
>
> On Jul 31, 12:31 am, Jonathan Lundell  wrote:
>
> > On Jul 31, 2009, at 12:16 AM, Bottiger wrote:
>
> > >> If the attacker knows (by reading the web2py source) that you're,  
> > >> say,
> > >> concatenating the base password three times, then he knows that you
> > >> haven't increased the password space by even one entry: there's a 1:1
> > >> mapping between base passwords and transformed passwords.
>
> > > So far you have kept on ignoring the gist of the problem. If the
> > > attacker has access to the salt, it doesn't matter whether or not you
> > > know the relationship between the password and the salt because you
> > > already know the salt. The attacker could not care less about whether
> > > you used a random number generator or a function related to the
> > > password.
>
> > >> If the attacker knows (by reading the web2py source) that you're,  
> > >> say,
> > >> concatenating the base password three times, then he knows that you
> > >> haven't increased the password space by even one entry: there's a 1:1
> > >> mapping between base passwords and transformed passwords.
>
> > > Can you please actually take some time to understand my previous
> > > comments? You could use a random 100 byte salt, and it
> > > wouldn't increase your password space for that password. All the
> > > attacker needs to do is this:
>
> > > for candidate in permutations(alphanumeric_and_symbols):
> > >  if md5(candidate+salt) == hash: return candidate
>
> > > This is the same brute force method that would be used when you have a
> > > completely random salt or a salt based on the password itself. Again I
> > > repeat, the attacker could not care less about whether you used a
> > > random number generator or a function related to the password.
>
> > The difference is that with a deterministic transform of the password  
> > (this includes static salt, or salt that's a function of the base  
> > password), the attacker performs your loop once and solves every  
> > password in his list. And the loop result can be precomputed into a  
> > rainbow table.
>
> > With random salt, the attacker must perform the loop (and it's a long  
> > loop) once for every hash he wants to attack. And the loop result  
> > cannot (practically) be precomputed.
>
> > OK? Deterministic transform means that one pass through the loop,  
> > precomputed, breaks all passwords in the permutation dictionary.
>
> > Random salt means that one pass through the loop breaks *one* password  
> > *if* it's in the permutation dictionary. And it can't be precomputed.
>
> > Again, it's no substitute for a strong password. But it helps.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27708] Re: Default CRYPT() is unsecure

[Julio]

On Jul 31, 1:19 am, Jonathan Lundell  wrote:
>
> I'm suggesting (sticking with md5 for comparability):
>
>         md5(password+random)+random
>
> ...where random is randomly chosen for each new password.
>
> You're suggesting?

How can you hash a password with a "random" salt??, the whole purpose
for the authentication logic is to be able to recreate the hash in
order to compare against what is stored in the database?, under this
premise let's scrap the entire hashing issue and just set the
passwords to str(random.random())[2:]  or am I missing something here?

Thx,

Julio
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27710] Re: Default CRYPT() is unsecure

[Jonathan Lundell]

On Jul 31, 2009, at 7:55 AM, Julio wrote:

> .. And even if you use the same salt for each password It'd still be a
> time-consuming job since for each "clear" password in a rainbow table
> you'd have to "recompute" the new hash based on the salt and scan the
> rainbow table entirely for each record, now I totally agree that
> adding a salt for each password (obviously it has to be predictable so
> we can generate the hash again at log in time) will strengthen the
> passwords greatly.
>
> My suggestion is simply implement the new salting algorithm, move the
> unsalted hashed password to a lookup table (which will be deleted
> eventually), and "expire" the passwords for all your users, and on the
> next logon, they will have to type the old one, then create a new one
> and this time it'll be hashed with the proper salt, this way, even
> though "compatibility" will break, we'll still have a means to
> "correct" this.
>
> The way I do it in pyforum for instance, is this:
>
> passwd = "Hello World"
> hashed_pwd_tmp = hashlib.md5(passwd).hexdigest()
> hashed_passwd = hashlib.md5("%s%s" % (tmp_hashed_pwd,
> passwd)).hexdigest()
>
> So basically I prepend (or append, I don't have the code at this time)
> the hashed password to the clear password and re-hash the whole string
> again, breakable? of course, but exponentially harder.

The problem with this approach (what I've been calling a deterministic  
password transform) is that it's no harder to precompute a new rainbow  
table, knowing the algorithm, which is public, than it was to compute  
the first rainbow table. Well, a little harder, since there are two  
md5's per entry instead of one, but that's all.

Consider instead:

passwd = "Hello World"
salt = random.randint(1, 100).str
hashed_pwd = hashlib.md5(passwd+salt).hexdigest()+salt

This expands the size of the required rainbow table by a factor of  
1,000,000.

The confusion here might be that we're assuming different attacks.  
Perhaps:

* you're assuming that the attack is to use an existing md5 rainbow  
table

* I'm assuming that the attack is to create a new rainbow table for  
web2py passwords


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27709] Re: Yet another WEB2PY application

[Gijsbert]

I'm no expert, but I have flash followed by a redirect not work.

On Jul 30, 6:23 am, Vidul Petrov  wrote:
> http://my-sticky-note.appspot.com/init/default/welcome(still missing
> the demo)
>
> Yes it's very small app, never-the-less the time went like this:
>  - views / controllers / model: 5% (or less)
>  - javascript / css: 95%
>
> I encountered only one small problem - some of the aith.messages do
> not appear in the flash, for example auth.messages.email_sent which
> was supposed to appear right after the registration.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27711] Re: file downloading problem

[Alex Fanjul]

take a look here:
http://www.mhproject.org/index.php/mhproject.php/2009/07/20/how_to_install_apache2_ssl_web2py_window
however, abraham told me that the wsgi version i use is old, but i
couldnt find updated one for python 2.5 , all are for 2.6
cheers
alex f

El 31/07/2009 14:48, 陶艺夫 escribió:
> Thank you for reply.
> I've been googling the right version of mod_wsgi for couples of hours
> and I got nothing. I'll try to compile it form the source code. I'm
> under windows xp [ :( ], python 2.5.4,apache 2.2.11.
> How can I compile it? Any instructions will be thankful.
>
> 2009/7/31 Yarko Tymciurak mailto:yark...@gmail.com>>
>
> I believe this is a cherrypy issue; Can you use apache + mod_wsgi
> instead? This is more reliable for serious work.
>
>
> On Thu, Jul 30, 2009 at 10:32 PM, 陶艺夫  > wrote:
>
> Hi,
> I'm using "response.stream(file_name)" method to offer users
> downloading files which are sort of business-classified, but
> the downloading process always terminated halfway. The testing
> file is 4.2M, an Excel workbook.
> Is there anything I can do with system
> configuration(CherryPy), or it's just an internet problem?
>
> thanks
>
>
>
>
>
>
>
> >

-- 
Alejandro Fanjul Fdez.
alex.fan...@gmail.com
www.mhproject.org

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27712] Re: Default CRYPT() is unsecure

[Jonathan Lundell]

On Jul 31, 2009, at 8:07 AM, Julio wrote:

> On Jul 31, 1:19 am, Jonathan Lundell  wrote:
>>
>> I'm suggesting (sticking with md5 for comparability):
>>
>> md5(password+random)+random
>>
>> ...where random is randomly chosen for each new password.
>>
>> You're suggesting?
>
> How can you hash a password with a "random" salt??, the whole purpose
> for the authentication logic is to be able to recreate the hash in
> order to compare against what is stored in the database?, under this
> premise let's scrap the entire hashing issue and just set the
> passwords to str(random.random())[2:]  or am I missing something here?

You're missing something. From my earlier post, you create the  
password thus (I've added a separator byte for convenience):

passwd = "Hello World"
salt = random.randint(1, 100).str
hashed_pwd = hashlib.md5(passwd+salt).hexdigest()+":"+salt

To check the password, retrieve the user's hashed_pwd from the user  
db, split it on ":" to retrieve the salt, append it to the password to  
be checked, and compare the hash of the result to the hash part of the  
split.

(I've used randint.str as a simple example; in practice you'd use a  
more dense representation, and while you're at it you'd use a better  
hash than md5.)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27713] Re: Default CRYPT() is unsecure

[Gijsbert]

I know next to nothing about this stuff, but yesterday I had to do
some stuff with htpasswd and I noticed you can actually use different
hash schemes in the same password file (at least I saw a mix of salted
and unsalted hashes). Couldn't this be used to solve the compatibility
issue? Assuming that you can recognize the hashing scheme from the
hash in the table, a new, more secure, algorithm could be added as
default and both old and new passwords would keep on working.

This is not as secure as forcing people to retype their password, like
Julio suggested, but at least it would make the default install more
secure.

my 2c

On Jul 31, 11:31 am, Jonathan Lundell  wrote:
> On Jul 31, 2009, at 8:07 AM, Julio wrote:
>
> > On Jul 31, 1:19 am, Jonathan Lundell  wrote:
>
> >> I'm suggesting (sticking with md5 for comparability):
>
> >>         md5(password+random)+random
>
> >> ...where random is randomly chosen for each new password.
>
> >> You're suggesting?
>
> > How can you hash a password with a "random" salt??, the whole purpose
> > for the authentication logic is to be able to recreate the hash in
> > order to compare against what is stored in the database?, under this
> > premise let's scrap the entire hashing issue and just set the
> > passwords to str(random.random())[2:]  or am I missing something here?
>
> You're missing something. From my earlier post, you create the  
> password thus (I've added a separator byte for convenience):
>
> passwd = "Hello World"
> salt = random.randint(1, 100).str
> hashed_pwd = hashlib.md5(passwd+salt).hexdigest()+":"+salt
>
> To check the password, retrieve the user's hashed_pwd from the user  
> db, split it on ":" to retrieve the salt, append it to the password to  
> be checked, and compare the hash of the result to the hash part of the  
> split.
>
> (I've used randint.str as a simple example; in practice you'd use a  
> more dense representation, and while you're at it you'd use a better  
> hash than md5.)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27714] Re: Default CRYPT() is unsecure

[Julio]

Both methods are really flawed and we all know it, adding a "random"
flavor to the salt (and storing it somewhere) is no more difficult to
"crack" than salting a password with the first, third and fifth
letters of the original password for example (or the way I am doing it
for that matter),

I believe we all know that MD5 is not the best hashing algorithm,
since it only supports 128-bit digest length, the problem is that we
are not *encrypting* our passwords, but rather hashing them, python
does not provide afaik a good encryption implementation (without the
use of 3rd parties), and implementing an encrypting algorithm will
surely render web2py incompatible with "earlier" versions.

It does not really matter what we "salt" our hashes with, they will
always be breakable, period. Now, assuming that we'll continue using
MD5(unsalted_passwd), the *truly* only way to "defeat" rainbow table
attacks is simple and does not involve breaking backwards
compatibility: Use strong passwords, if your password is [myname]
[myDOB], you *deserve* to be hacked (I'm kidding of course).

Thx,

Julio

On Jul 31, 8:31 am, Jonathan Lundell  wrote:
> You're missing something. From my earlier post, you create the  
> password thus (I've added a separator byte for convenience):
>
> passwd = "Hello World"
> salt = random.randint(1, 100).str
> hashed_pwd = hashlib.md5(passwd+salt).hexdigest()+":"+salt
>
> To check the password, retrieve the user's hashed_pwd from the user  
> db, split it on ":" to retrieve the salt, append it to the password to  
> be checked, and compare the hash of the result to the hash part of the  
> split.
>
> (I've used randint.str as a simple example; in practice you'd use a  
> more dense representation, and while you're at it you'd use a better  
> hash than md5.)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27715] Re: Default CRYPT() is unsecure

[Francisco Gama]

On Jul 31, 6:26 am, Bottiger  wrote:
> > That may not be a good idea, I think. That makes your password longer but 
> > with a possible cryptographic weakness because it's following a known 
> > generation rule (being formed by a string repeated 3 times).
>
> The primary concern is a precomputed rainbow hash table.

I know, but brute force attacks are also a threat.

if I was an attacker and I find that the password field size is 32
bytes (e.g.) and the password generation always follows that rule you
described I can make a brute force attack that excludes a lot of
possible password in that 32 bytes domain such as passwords that
aren't formed by the rule you described, passwords that are smaller
than the minimum allowed password size * 3 and any password that has a
length larger than 32 bytes / 3 and I probably could go on more
password domain restrictions.

Am I wrong?

>
> Anything related to password generation strength depends on the
> person's original password and even a random salt does not help,
> because if the database is compromised, then the attack knows which
> salt to generate hashes for. Therefore there really isn't anything
> wrong with just doubling or tripling the password as a salt.
>
> In fact, many websites such as Reddit (which I examined the source
> code) does this.
>
> On Jul 30, 9:51 pm, Francisco Gama  wrote:
>
>
>
> > On Jul 31, 5:16 am, Bottiger  wrote:
>
> > > As long as the salt is different for every password, it pretty much
> > > makes it infeasible for someone to create a large enough rainbow hash
> > > table attack.
>
> > > The Unix salt of 12 random bytes is ok, but comes at the cost of extra
> > > storage and pretty much the same benefit. To put a larger barrier on
> > > computational speed, you could double or triple the original password
> > > before putting it through the hash.
>
> > That may not be a good idea, I think. That makes your password longer
> > but with a possible cryptographic weakness because it's following a
> > known generation rule (being formed by a string repeated 3 times).
> > That makes the diversity of possible passwords much smaller which
> > isn't a good password policy.
>
> > Besides, the complexity is the same (which is close to say that the
> > computational speed is also close) and an attacker would need the same
> > number of attempts to break the password by brute force because all he
> > had to for each attempt X, the attempt XXX. He doesn't need to try X
> > or XX.
>
> > > On Jul 30, 8:38 pm, Jonathan Lundell  wrote:
>
> > > > On Jul 30, 2009, at 8:30 PM, Bottiger wrote:
>
> > > > > I know you have the mantra of not breaking backwards compatibility,
> > > > > but it is a pretty bad idea to have unsalted MD5 passwords.
>
> > > > > For example, let's say your password is "massimo". The MD5 hash of
> > > > > that happens to be "8cac5ac44b51f182143a43c4cdb6c4ac".
>
> > > > > Even forgetting rainbow tables, you can simply do a search for it on
> > > > > Google and you have 10+ pages telling you that it is the hash for
> > > > > "massimo".
>
> > > > How about a new validator that does the right thing, and deprecating  
> > > > CRYPT?
>
> > > > I'd prefer some less-predictable salt than the suggestion below,  
> > > > though. How about the old Unix passwd trick of choosing a some random  
> > > > salt, and appending the salt in plaintext to the hash?
>
> > > > >http://www.google.com/search?q=8cac5ac44b51f182143a43c4cdb6c4ac
>
> > > > > On Jul 30, 8:10 pm, mdipierro  wrote:
> > > > >> We cannot break backward compatibility. People should specify a key
> > > > >> and use the HMAC+SHA512 anyway.
>
> > > > >> Massimo
>
> > > > >> On Jul 30, 9:49 pm, Bottiger  wrote:
>
> > > > >>> The CRYPT validator is unsecure because it uses unsalted MD5.
>
> > > > >>> There are public rainbow tables that have unsalted MD5 passwords  
> > > > >>> of up
> > > > >>> to 10 characters long including symbols.
>
> > > > >>> I highly recommend that if no "key" is specified, that CRYPT will
> > > > >>> automatically salt the password based on a substring of the password
> > > > >>> itself. For example:
>
> > > > >>> password = "secretpass"
> > > > >>> hash = md5(password+password[-1])
>
> > > > >>> This will of course break backward compatibility, but this is a real
> > > > >>> security vulnerability.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27716] Re: Default CRYPT() is unsecure

[Jonathan Lundell]

On Jul 31, 2009, at 9:35 AM, Gijsbert wrote:

> I know next to nothing about this stuff, but yesterday I had to do
> some stuff with htpasswd and I noticed you can actually use different
> hash schemes in the same password file (at least I saw a mix of salted
> and unsalted hashes). Couldn't this be used to solve the compatibility
> issue? Assuming that you can recognize the hashing scheme from the
> hash in the table, a new, more secure, algorithm could be added as
> default and both old and new passwords would keep on working.
>
> This is not as secure as forcing people to retype their password, like
> Julio suggested, but at least it would make the default install more
> secure.

Exactly. If the user's password validates with the old (weak) hash,  
rehash it with a stronger hash and write it back to the user table.  
That way the hash, at least, gets updated as soon as a user logs in.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27717] Re: Default CRYPT() is unsecure

[Jonathan Lundell]

On Jul 31, 2009, at 9:36 AM, Julio wrote:

> Both methods are really flawed and we all know it, adding a "random"
> flavor to the salt (and storing it somewhere) is no more difficult to
> "crack" than salting a password with the first, third and fifth
> letters of the original password for example (or the way I am doing it
> for that matter),
>
> I believe we all know that MD5 is not the best hashing algorithm,
> since it only supports 128-bit digest length, the problem is that we
> are not *encrypting* our passwords, but rather hashing them, python
> does not provide afaik a good encryption implementation (without the
> use of 3rd parties), and implementing an encrypting algorithm will
> surely render web2py incompatible with "earlier" versions.
>
> It does not really matter what we "salt" our hashes with, they will
> always be breakable, period. Now, assuming that we'll continue using
> MD5(unsalted_passwd), the *truly* only way to "defeat" rainbow table
> attacks is simple and does not involve breaking backwards
> compatibility: Use strong passwords, if your password is [myname]
> [myDOB], you *deserve* to be hacked (I'm kidding of course).

We should be clear about which problem(s) we're trying to solve.

1. Any really secure mechanism is going to require a strong password,  
and probably more than that, such as a two-factor method. But we know  
that we can't impose a strong-password requirement on every application.

2. Weak passwords are subject to a blind, brute-force dictionary  
attack. Nothing we do with the hash is going to help this; the  
attacker never has to compute a hash. We can mitigate it by rate- 
limiting password attempts, and we should probably do that, perhaps by  
adding a timestamp to the user table that remembers the last password  
attempt, and imposing a delay before attempting another validation, or  
by locking out a user after some number of failed attempts.

3. If the attacker has access to the user table (user names plus  
hashed passwords), then he can mount an offline brute force attack.  
How practical this is depends on how big the attacker's dictionary is,  
and of course how likely it is that a user has chosen a password weak  
enough to be in the dictionary. Note that an HMAC defends against this  
attack by using a secret key, which acts effectively as "secret salt".  
The problem with this is that, if you assume that you can't keep the  
user table secret, then how can you assume that you can keep the HMAC  
key secret? Still, it's something.

4. Rainbow tables are a special case (3) above. The point of this  
attack is that, once the table is computed, it's *very fast* to  
determine whether a given hashed password is in the table. The reason  
that random salt is a defense against this attack is that it makes the  
rainbow table impractically large. Don't confuse a rainbow-table  
attack with a brute-force attack against a known hashed password (3  
above).

5. Secret salt is even better, but then we're back to the question of  
how to keep the salt secret when we're assuming that we can't keep the  
hashes secret.


Here's another test you can apply to salting systems. If two users  
choose the same (plaintext) password, what are the chances that  
they'll end up with the same hash? With simple md5, with or without a  
deterministic transformation of the plaintext, the hashes will always  
be the same. With random salt, even if the salt is not secret, the  
chance of a collision can be made arbitrarily small.


See the Wikipedia entries on salt: 
http://en.wikipedia.org/wiki/Salt_(cryptography) 
  and rainbow tables: http://en.wikipedia.org/wiki/Rainbow_table


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27718] Re: file downloading problem

[陶艺夫]

Thank Alex. I have followed your instructions to set up the whole
envirenment. After restart all sevices, I still can't get it work. And there
are some warning in the Apache log error log file:

[Sat Aug 01 00:37:43 2009] [warn] mod_wsgi: Compiled for Python/2.5.
[Sat Aug 01 00:37:43 2009] [warn] mod_wsgi: Runtime using Python/2.5.4.
[Sat Aug 01 00:37:43 2009] [warn] mod_wsgi: Python module path
'C:\\WINDOWS\\system32\\python25.zip;D:\\Python25\\Lib;D:\\Python25\\DLLs;D:\\Python25\\Lib\\lib-tk;;D:\\wamp\\bin\\apache\\apache2.2.11\\bin'.
[Sat Aug 01 00:37:43 2009] [notice] Apache/2.2.11 (Win32) mod_ssl/2.2.11
OpenSSL/0.9.8k PHP/5.3.0 mod_wsgi/2.3 Python/2.5.4 configured -- resuming
normal operations
[Sat Aug 01 00:37:43 2009] [notice] Server built: Dec 10 2008 00:10:06
[Sat Aug 01 00:37:43 2009] [notice] Parent: Created child process 4308
[Sat Aug 01 00:37:43 2009] [warn] Init: Session Cache is not configured
[hint: SSLSessionCache]

And I can't get the 2.5 (not 2.5.1-2.5.4) version of python from Python
official website, it's gone?


2009/7/31 Alex Fanjul 

>  take a look here:
> http://www.mhproject.org/index.php/mhproject.php/2009/07/20/how_to_install_apache2_ssl_web2py_window
> however, abraham told me that the wsgi version i use is old, but i couldnt
> find updated one for python 2.5 , all are for 2.6
> cheers
> alex f
>
> El 31/07/2009 14:48, 陶艺夫 escribió:
>
> Thank you for reply.
> I've been googling the right version of mod_wsgi for couples of hours and I
> got nothing. I'll try to compile it form the source code. I'm under windows
> xp [ :( ], python 2.5.4,apache 2.2.11.
> How can I compile it?  Any instructions will be thankful.
>
> 2009/7/31 Yarko Tymciurak 
>
>> I believe this is a cherrypy issue;  Can you use apache + mod_wsgi
>> instead?  This is more reliable for serious work.
>>
>> On Thu, Jul 30, 2009 at 10:32 PM, 陶艺夫  wrote:
>>
>>> Hi,
>>> I'm using "response.stream(file_name)" method to offer users downloading
>>> files which are sort of business-classified, but the downloading process
>>> always terminated halfway. The testing file is 4.2M, an Excel workbook.
>>> Is there anything I can do with system configuration(CherryPy), or  it's
>>> just an internet problem?
>>>
>>> thanks
>>>
>>>
>>>
>>
>>
>>
>
>
>
> --
> Alejandro Fanjul Fdez.
> alex.fan...@gmail.com
> www.mhproject.org
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27719] Re: Default CRYPT() is unsecure

[olivier]

> I'd prefer some less-predictable salt than the suggestion below,  
> though. How about the old Unix passwd trick of choosing a some random  
> salt, and appending the salt in plaintext to the hash?

we could do that, without braking backward compatibility i think...
- store password in the following format:   hashtype$salt
$passwordhash  (with '$' separators, pretty standard stuff...)

to authenticate user:
- add a special case:   if no hashtype:  passwordhash -> md5$
$passwordhash
- use hashtype(password + salt),  for most of the standard hashtypes
(md5, sha1, sha256, ...)
(- do other weird stuffs...  like add a special hashtype bottiger,
bottiger$$passwordhash   will use the function md5( f(password) ) , f
being a deterministic function ) ;-)

we could add a special attribute for migration. if set to True, then
storage is migrated from the old format to the new format when user
logs in
the length of the salt can also be a parameter (if you really want to
play with some trade-off between storage/security, bad idea)

i can work on that, if it makes sense to you guys

 -olivier

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27720] problem with web2py, gae, and taskqueue

[David Watson]

Has anybody had any luck getting the taskqueue from google app engine
to work in web2py? I presume that it should work under dev_appserver,
but isn't working for me.

I defined a simple default controller based on the gae example at the
google blog:

def process_post_file():
rows=db(db.files.processed=='False').select(db.files.ALL)
for row in rows:
f = row.file_blob
email_addresses = f.split('\n')
for email_address in email_addresses:
taskqueue.add(url='/init/default/sendmail', params=dict
(to=email_address, subject='Hello ' + email_address, body='this is a
message!'))
return dict(message=T('mail was queued'))

def sendmail():
mail.send_mail(
'm...@my.com', # needs to be from settings
request.vars['to'],
request.vars['subject'],
request.vars['body'])

but my sendmail function never gets called. Everything seems fine up
through the task queue, but no callback.

Thanks,
David
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27721] Re: Default CRYPT() is unsecure

[Jonathan Lundell]

On Jul 31, 2009, at 3:33 AM, olivier wrote:

>>
>> I'd prefer some less-predictable salt than the suggestion below,
>> though. How about the old Unix passwd trick of choosing a some random
>> salt, and appending the salt in plaintext to the hash?
>
> we could do that, without braking backward compatibility i think...
> - store password in the following format:   hashtype$salt
> $passwordhash  (with '$' separators, pretty standard stuff...)
>
> to authenticate user:
> - add a special case:   if no hashtype:  passwordhash -> md5$
> $passwordhash
> - use hashtype(password + salt),  for most of the standard hashtypes
> (md5, sha1, sha256, ...)
> (- do other weird stuffs...  like add a special hashtype bottiger,
> bottiger$$passwordhash   will use the function md5( f(password) ) , f
> being a deterministic function ) ;-)
>
> we could add a special attribute for migration. if set to True, then
> storage is migrated from the old format to the new format when user
> logs in
> the length of the salt can also be a parameter (if you really want to
> play with some trade-off between storage/security, bad idea)
>
> i can work on that, if it makes sense to you guys

It makes sense to me.

We might also want to require a strong password by default (if we're  
not already), which would also be backward compatible. I was writing  
up a separate message on tightening up password security generally;  
I'll send it shortly.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27722] Re: Default CRYPT() is unsecure

[Julio]

On Jul 31, 10:13 am, Jonathan Lundell  wrote:
>
> We should be clear about which problem(s) we're trying to solve.
>

Hey Jon,

I think this is the easiest part, we are trying to secure our
passwords (without using encryption) so in the event they are stolen
they would be *very hard* to crack, simple (at least to say anyway).

I repeat myself, any approach to salting, deterministic as you refer
to or pseudo-random yields the exact same results, they will be hard
[er] to crack, but crackable none the less, consider this:

>>> md5.md5('hello').hexdigest()
'5d41402abc4b2a76b9719d911017c592'

Then google the results (more than 20,000 hits right?)

Now let's harden it:

>>> md5.md5('%shello' % (md5.md5('hello').hexdigest())).hexdigest()
'f62b484dd6745a5065fe4fa7b0004100'

0 results

Now, let's do this:

>>> md5.md5('764928348712hello').hexdigest()
'8cbf1c0ce99bad31172e9e9584d11454'

0 google results

Now, you may say, the "random" number pre-pended to the password is
more "secure" than using a unique (per record) salt, when in fact they
are both crackable to the exact same degree, since the "salt" used is
stored somewhere anyway.

Now salting, as long as the salt is unique (not random) per record all
it does it that it makes too much harder to crack using rainbow
tables, since for each record in your stolen table you will need to
generate the entire rainbow table with each individual salt, a very
time consuming task, that's it.

>
> Here's another test you can apply to salting systems. If two users  
> choose the same (plaintext) password, what are the chances that  
> they'll end up with the same hash? With simple md5, with or without a  
> deterministic transformation of the plaintext, the hashes will always  
> be the same. With random salt, even if the salt is not secret, the  
> chance of a collision can be made arbitrarily small.

So what's the problem? we are hashing, not encrypting, meaning that it
is possible that my password is v...@1dr897 and some other user having
the password as 77d772s!@ we both end up with the same hashed data
effectively causing a collision.. For the hacker, he'll just see two
hashes with the same value.. does this mean that they are both the
same password?..

I mean for the most part I agree with you, the issue I am trying to
prove is that salting, as long as it is unique does not matter if it
comes from a pseudo random salt value or a unique value assigned to
each record (assuming that the random value used for the salting
process is also stolen)..

Julio
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27723] Re: Default CRYPT() is unsecure

[Jonathan Lundell]

On Jul 31, 2009, at 12:10 PM, Julio wrote:

>
> On Jul 31, 10:13 am, Jonathan Lundell  wrote:
>>
>> We should be clear about which problem(s) we're trying to solve.
>>
>
> Hey Jon,
>
> I think this is the easiest part, we are trying to secure our
> passwords (without using encryption) so in the event they are stolen
> they would be *very hard* to crack, simple (at least to say anyway).
>
> I repeat myself, any approach to salting, deterministic as you refer
> to or pseudo-random yields the exact same results, they will be hard
> [er] to crack, but crackable none the less, consider this:
>
 md5.md5('hello').hexdigest()
> '5d41402abc4b2a76b9719d911017c592'
>
> Then google the results (more than 20,000 hits right?)
>
> Now let's harden it:
>
 md5.md5('%shello' % (md5.md5('hello').hexdigest())).hexdigest()
> 'f62b484dd6745a5065fe4fa7b0004100'
>
> 0 results
>
> Now, let's do this:
>
 md5.md5('764928348712hello').hexdigest()
> '8cbf1c0ce99bad31172e9e9584d11454'
>
> 0 google results
>
> Now, you may say, the "random" number pre-pended to the password is
> more "secure" than using a unique (per record) salt, when in fact they
> are both crackable to the exact same degree, since the "salt" used is
> stored somewhere anyway.
>
> Now salting, as long as the salt is unique (not random) per record all
> it does it that it makes too much harder to crack using rainbow
> tables, since for each record in your stolen table you will need to
> generate the entire rainbow table with each individual salt, a very
> time consuming task, that's it.

I think you might be confusing a brute-force known-hash attack on a  
single password with a known-hash attack that involves creating a  
rainbow table for a particular hash function.

The reason you get no Ghits for the hash you searched for is that  
nobody has created a rainbow table for that particular function and  
put it on the web. That's not really much of a security guarantee.

A side note. Consider some hash(password). For some dictionary of  
passwords, we can create a rainbow table that effectively maps the  
hash back to the password, which is an effective attack against weak  
passwords (defined as passwords in the dictionary) and a non-secret  
hash.

If we have a deterministic (1:1) transform t() of the password, then  
hash(t(password)) is exactly some hash'(password). We've redefined the  
hash function, and all we have to do is to create a new rainbow table  
for that function. That is, you can consider any 1:1 pre-hash  
transform of the password to be part of the hash function itself.  
Sure, if hash() was md5(), then hash'() will be something else, and  
you won't be able to take advantage of public rainbow tables. But you  
can create your own rainbow table for hash'.

Random salt addresses this problem by hashing each password into one  
of millions (or billions or trillions) of possible hashes. Because the  
salt isn't secret, it's still vulnerable to a brute-force known-hash  
attack, but it's no longer vulnerable to a rainbow-table attack, which  
is the point of random non-secret salt.


>
>>
>> Here's another test you can apply to salting systems. If two users
>> choose the same (plaintext) password, what are the chances that
>> they'll end up with the same hash? With simple md5, with or without a
>> deterministic transformation of the plaintext, the hashes will always
>> be the same. With random salt, even if the salt is not secret, the
>> chance of a collision can be made arbitrarily small.
>
> So what's the problem? we are hashing, not encrypting, meaning that it
> is possible that my password is v...@1dr897 and some other user having
> the password as 77d772s!@ we both end up with the same hashed data
> effectively causing a collision.. For the hacker, he'll just see two
> hashes with the same value.. does this mean that they are both the
> same password?..

For all practical purposes, yes it does. That's one reason we probably  
want to use a longer hash than MD5.

>
> I mean for the most part I agree with you, the issue I am trying to
> prove is that salting, as long as it is unique does not matter if it
> comes from a pseudo random salt value or a unique value assigned to
> each record (assuming that the random value used for the salting
> process is also stolen)..

If you still think that, please read the Wikipedia articles I  
referenced (rainbow tables and salt) more carefully.

>
> Julio




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27724] backward-compatible CRYPT() upgrades

[Jonathan Lundell]

There are several measures we might take to tighten up default  
security in a backwards-compatible way.

1. Use IS_STRONG() by default in the welcome application template.

2. Add salted hash methods, in particular a) random salt, and b) using  
the user's email address as salt (it's not as good as random salt, but  
it doesn't have to be appended to the hash, since it's already  
available).

3. Add a meta hash method for migrating hashes. Let a site that's  
using currently using some WEAKHASH() (default CRYPT() in particular)  
to specify a hash type of MIGRATEHASH(WEAKHASH, STRONGHASH). The rule  
for this method is to always use STRONGHASH, with one exception: on  
login, if STRONGHASH fails, try WEAKHASH. If WEAKHASH succeeds, then  
update the user table with STRONGHASH.

4. Given (2) and (3), then by default CRYPT() could be redefined as  
MIGRATEHASH(OLDCRYPT, STRONGHASH), for some strong hash.

5. Add a defense against blind brute-force attacks by rate-limiting  
login attempts, but some method tbd.

6. Consider some mechanism that requires a user to choose a new  
password (aging, perhaps), so that IS_STRONG can be enforced.

7. Encrypt the user table (or at least critical fields in it) with a  
secret key, so that if someone gains access to the database, they  
don't get access to email addresses or password hashes. This raises  
the question of how to keep the secret key secret, but at the very  
least it can be kept separate from the database, say in an access- 
controlled file in the filesystem.

8. Note that (7) introduces the general problem of secret-key  
management, which is also an issue for HMACs. Some general solution  
would be nice.

9. Finally, none of this helps against a stolen-password attack. For  
that, we ought to be supporting two-factor authentication. I assume  
that we can do this already via third-party methods; perhaps we could  
identify someone supporting something like the Verisign dongle.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27725] Re: Default CRYPT() is unsecure

[Julio]

> If we have a deterministic (1:1) transform t() of the password, then  
> hash(t(password)) is exactly some hash'(password). We've redefined the  
> hash function, and all we have to do is to create a new rainbow table  
> for that function. That is, you can consider any 1:1 pre-hash  
> transform of the password to be part of the hash function itself.  
> Sure, if hash() was md5(), then hash'() will be something else, and  
> you won't be able to take advantage of public rainbow tables. But you  
> can create your own rainbow table for hash'.
>

I think here is where the source of confusion is, for the record I am
not talking a brute force known hash attack (which incidentally the
"random" salt used in your approach become "known" anyway).

If I read you correctly, you are saying that all you need to do is
generate a custom rainbow table with hash(t(password)) and you'll be
set, what I am saying is that you will have to generate that custom
rainbow table for *each* record you'd like to crack, now my point is
that your approach is exactly the same as the one I said earlier, by
adding a pseudo-random number as the salt, and that salt is 100%
discoverable (deterministic) you are just playing the same game but
with a different ball.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27726] Re: Default CRYPT() is unsecure

[Jonathan Lundell]

On Jul 31, 2009, at 12:56 PM, Julio wrote:

>> If we have a deterministic (1:1) transform t() of the password, then
>> hash(t(password)) is exactly some hash'(password). We've redefined  
>> the
>> hash function, and all we have to do is to create a new rainbow table
>> for that function. That is, you can consider any 1:1 pre-hash
>> transform of the password to be part of the hash function itself.
>> Sure, if hash() was md5(), then hash'() will be something else, and
>> you won't be able to take advantage of public rainbow tables. But you
>> can create your own rainbow table for hash'.
>>
>
> I think here is where the source of confusion is, for the record I am
> not talking a brute force known hash attack (which incidentally the
> "random" salt used in your approach become "known" anyway).
>
> If I read you correctly, you are saying that all you need to do is
> generate a custom rainbow table with hash(t(password)) and you'll be
> set, what I am saying is that you will have to generate that custom
> rainbow table for *each* record you'd like to crack,

No, that's not the case. You need only one rainbow table for the new  
hash' function and you're done.

hash(t(p)) is simply hash'(p), and all you need is the rainbow table  
for hash' instead of hash.

But this only works when t(p) is a 1:1 transform, and that's not the  
case for random salt, even if the salt is non-secret.

> now my point is
> that your approach is exactly the same as the one I said earlier, by
> adding a pseudo-random number as the salt, and that salt is 100%
> discoverable (deterministic) you are just playing the same game but
> with a different ball.



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27727] Error when replacing default auth tables.

[ivanvpan]

Hello forum!
I am trying to replace the default auth table 'auth_user' with my own:
auth.settings.table_user = db.define_table(
auth.settings.table_user_name,
Field('username', length=32, requires = [IS_NOT_EMPTY(), IS_LENGTH
(32), IS_ALPHANUMERIC()]),
Field('email', length=128,default='', requires = [IS_EMAIL(),
IS_NOT_EMPTY()]),
Field('password', 'password', readable=False,
 label='Password', requires=CRYPT(digest_alg='sha512')),
Field('registration_key', length=128,
 writable=False, readable=False, default=''))
auth.define_tables()

The table gets created, but when I try to register a user it seems
like web2py is trying to access columns from the default table (which
aren't there):
  File "/home/.../web2py/applications/feed/controllers/read.py", line
44, in index
return dict(next=next, prev=prev, entries=entries, feeds=feeds,
login_form=auth())
  File "/home/.../web2py/gluon/tools.py", line 466, in __call__
return self.register()
  File "/home/.../web2py/gluon/tools.py", line 880, in register
% form.vars
KeyError: 'first_name'

Dropped tables, created fresh ones, restarted web2py. Framework is
latest version.
Thanks!

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27728] Re: Error when replacing default auth tables.

[Yarko Tymciurak]

You have some errors here:

On Fri, Jul 31, 2009 at 4:47 PM, ivanvpan  wrote:

>
> Hello forum!
> I am trying to replace the default auth table 'auth_user' with my own:
> auth.settings.table_user = db.define_table(
>auth.settings.table_user_name,


this can also be:

auth.settings.table_user = db.define_table( "auth_user",

the rest of the mandatory fields you can see on slide 125 at www.web2py.com,
or
as shown on http://www.web2py.com/examples/default/tools

You can add your own fields, but you must have the minumum fields, as they
are written.


>
>Field('username', length=32, requires = [IS_NOT_EMPTY(), IS_LENGTH
> (32), IS_ALPHANUMERIC()]),
>Field('email', length=128,default='', requires = [IS_EMAIL(),
> IS_NOT_EMPTY()]),
>Field('password', 'password', readable=False,
> label='Password', requires=CRYPT(digest_alg='sha512')),
>Field('registration_key', length=128,
> writable=False, readable=False, default=''))
> auth.define_tables()
>
> The table gets created, but when I try to register a user it seems
> like web2py is trying to access columns from the default table (which
> aren't there):
>  File "/home/.../web2py/applications/feed/controllers/read.py", line
> 44, in index
>return dict(next=next, prev=prev, entries=entries, feeds=feeds,
> login_form=auth())
>  File "/home/.../web2py/gluon/tools.py", line 466, in __call__
>return self.register()
>  File "/home/.../web2py/gluon/tools.py", line 880, in register
>% form.vars
> KeyError: 'first_name'


This is because you defined a field "username", but the auth system is
looking for a field "first_name" -

as I said, the basic fields must be entered as shown, at a minimum.

Hope this helps,

- Yarko


>
>
> Dropped tables, created fresh ones, restarted web2py. Framework is
> latest version.
> Thanks!
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27729] Re: Error when replacing default auth tables.

[ivanvpan]

> You can add your own fields, but you must have the minumum fields, as they
> are written.
Ah! That's the ticket. Thanks a lot.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27730] Tutorial: Using Geraldo with Web2Py

[Fran]

http://web2py.com/AlterEgo/default/show/246

Will hopefully be added to main Geraldo docs too:
https://sourceforge.net/tracker/?func=detail&aid=2830566&group_id=251460&atid=1126588

This is all working great for me with simple reports, however I am
currently unable to get SubReports to workhas anyone else got this
working?

Within Django this is done as:
queryset_string = '%(object)s.purchaseitem_set.all()'

I am trying to replicate this using something like:
queryset_string = 'db(db.purchaseitem.purchase==%(object)s.id).select
()'

but the class can't see 'db'
I therefore extended the Report class (from
http://github.com/marinho/geraldo/blob/7951ad4c2f984b9c8aff3ad67537d6da22a3ba70/geraldo/base.py)
to pass this in:
class MyReport(Report):
def __init__(self, queryset=None, db=None):
" Initialise parent class & make any necessary
modifications "
Report.__init__(self, queryset)
self.db = db

report = MyReport(queryset=purchases, db=db)

But I can't see how to pass from here into the SubReport.

queryset_string = 'self.db(self.db.purchaseitem.purchase==%(object)
s.id).select()'
fails as:
NameError: name 'self' is not defined

This seems to be because the class isn't instantiated at this point.

I tried extending the child class:
class MySubReport(SubReport):
def __init__(self, db=None, **kwargs):
" Initialise parent class & make any necessary
modifications "
SubReport.__init__(self, **kwargs)
self.db = db

But I get the same issue since can't pass 'db' across as not
instantiated...

Full code here (look at kit_export_pdf()):
http://trac.sahanapy.org/browser/controllers/budget.py

Suggestions welcomed :)

F
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27731] Re: Can I use HTTP PUT method?

[mdipierro]

I do not know for sure because PUT and DELETE are not standard http
methods. Try

request.vars
and
request.body.read()

Let us know.

On Jul 31, 2:28 am, 诚子  wrote:
> Hi, I wan't use PUT method and DELETE method,to build a RESTful
> service,how to get an PUT method and DELETE data?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27732] Re: executing a sql script

[mdipierro]

This should work

On Jul 31, 2:37 am, Fran  wrote:
> On Jul 31, 8:09 am, max  wrote:
>
> > for me the difficult part is to how i intgrate my xml parsing program
> > to the files which i have uploaded throgh web2py.
> > I want it  this way.
> > 1. Upload the xml file and a zip file
> >    implemented with web2py
> > 2. parse the content from the xml file and insert the data into a
> > mysql databse
> > i can generate the sql insert statesments with my xml parser.
> > interesting in knowing how i can insert this commands on the fly.
> > 3. copy the content of the zip file to a specific folder other than
> > upload folder
> > have  written a simple file copy mechanism,  how can i execute this
> > script using web2py
>
> Can this be done via an onvalidation callback?
> onvalidation = lambda form: myParser(form)
> form = crud.create(db.table_with_uploadfield,
> onvalidation=onvalidation)
>
> I'm interested in ensuring this works as I'll need it to be able to
> handle KMZ files & KML with Network Links inside...so pls feedback on
> whether onvalidation works as-is or whether upload fields need special
> handling...
>
> F
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27733] Re: Yet another WEB2PY application

[mdipierro]

If you want to display the flash after redirect you should use
session.flash and not response.flash

On Jul 31, 10:13 am, Gijsbert  wrote:
> I'm no expert, but I have flash followed by a redirect not work.
>
> On Jul 30, 6:23 am, Vidul Petrov  wrote:
>
> >http://my-sticky-note.appspot.com/init/default/welcome(stillmissing
> > the demo)
>
> > Yes it's very small app, never-the-less the time went like this:
> >  - views / controllers / model: 5% (or less)
> >  - javascript / css: 95%
>
> > I encountered only one small problem - some of the aith.messages do
> > not appear in the flash, for example auth.messages.email_sent which
> > was supposed to appear right after the registration.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27734] Re: file downloading problem

[mdipierro]

which browser are you using? can you try wget and/or other browsers?

On Jul 30, 10:32 pm, 陶艺夫  wrote:
> Hi,
> I'm using "response.stream(file_name)" method to offer users downloading
> files which are sort of business-classified, but the downloading process
> always terminated halfway. The testing file is 4.2M, an Excel workbook.
> Is there anything I can do with system configuration(CherryPy), or  it's
> just an internet problem?
>
> thanks
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27735] Re: Can I use HTTP PUT method?

[Jonathan Lundell]

On Jul 31, 2009, at 4:00 PM, mdipierro wrote:

> I do not know for sure because PUT and DELETE are not standard http
> methods.

They are, actually; they're just not used by interactive web browsers.

http://en.wikipedia.org/wiki/Http#Request_methods

> Try
>
> request.vars
> and
> request.body.read()
>
> Let us know.
>
> On Jul 31, 2:28 am, 诚子  wrote:
>> Hi, I wan't use PUT method and DELETE method,to build a RESTful
>> service,how to get an PUT method and DELETE data?
>



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27736] Re: Can I use HTTP PUT method?

[Yarko Tymciurak]

Hmmm  check this page out:

http://www.w3.org/Amaya/User/Put.html

On Fri, Jul 31, 2009 at 6:07 PM, Jonathan Lundell wrote:

>
> On Jul 31, 2009, at 4:00 PM, mdipierro wrote:
>
> > I do not know for sure because PUT and DELETE are not standard http
> > methods.
>
> They are, actually; they're just not used by interactive web browsers.
>
> http://en.wikipedia.org/wiki/Http#Request_methods
>
> > Try
> >
> > request.vars
> > and
> > request.body.read()
> >
> > Let us know.
> >
> > On Jul 31, 2:28 am, 诚子  wrote:
> >> Hi, I wan't use PUT method and DELETE method,to build a RESTful
> >> service,how to get an PUT method and DELETE data?
> >
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27737] Re: OpenID for Web2Py

[Bottiger]

Is anyone working on incorporating OpenID with auth? I need to know
because I am not looking forward to duplicating effort again if
someone has already started or finished it.

On Jul 27, 1:07 am, hcvst  wrote:
> Hi,
>
> when I first came across this post, I was working on a provider so I
> just posted my code.
> I think the only difference is that my version uses the Web2pyStore -
> the rest uses the Janrain
> Python openID library, just as Massimo's original implementation
> does.  As I had a working example, I
> did not look much deeper into what was already here, as the example
> here used the FileStore
> and I wanted to use the web2py DB.
>
> I do not know what Dave and his team are planning to build, but I
> guess it will be a bigger app.
>
> I am planning to add some helpers to w2popenid so that it's easier to
> use.  A bit like Auth()
>
> ---
> def server(): return dict(server=w2popenid.Server())
> def foo():
>       oresp = w2popenid.Consumer().check('myOpenID')
>       ...
> ---
>
> @Dave, what are you building? :-) I really really need a full featured
> openID provider for web2py.
> My first attempt (the whole w2popenid thing is derived from it) is
> here:http://github.com/hcvst/icy-openid
> and intended to replace the php! provider athttp://icy.co.zaasap.
> Can we work together?
>
> Regards,
> HC
>
> On Jul 27, 7:45 am, Bottiger  wrote:
>
> > So is hcvst part of your team of 3 people?
>
> > I don't understand why Massimo is asking you to maintain it when the
> > code seems to be coming from hcvst.
>
> > I am asking because I was trying to turn this into a cooperative
> > situation, and then two different people started hacking together
> > their own implementation. Not that I'm complaining, well actually I
> > am, because I felt like I just duplicated effort and didn't get any
> > recognition. But if you two are planning to do long term maintenance
> > and features, then I suppose I'm fine with that.
>
> > On Jul 26, 7:16 pm, dlypka  wrote:
>
> > > Great use of T3...
> > > OK, I will have a look in detail over the next few days..
> > > It is a wonderful contribution.
>
> > > On Jul 26, 7:00 am, hcvst  wrote:
>
> > > > Hi,
>
> > > > both the consumer and the provider sample apps are now available for
> > > > download fromhttp://w2popenid.appspot.com
>
> > > > I have also include some rudimentary HOWTOs on how to use them and on
> > > > how
> > > > to build your own.
>
> > > > Code and doc still require clean-up, but I am sure you did not expect
> > > > anything else.
>
> > > > @Dave, I have also tried to address your questions regarding XRI and
> > > > provider usage
> > > > in general.
>
> > > > Regards,
> > > > HC
>
> > > > =hc
>
> > > > On Jul 26, 12:29 pm, dlypka  wrote:
>
> > > > > I have my own team of 3 developers now, and web2py openid happens to
> > > > > be our current task,
> > > > > so I believe we have the manpower to help with and/or maintain it.
> > > > > I'll keep everyone here posted with our progress and source code.
>
> > > > > We also have some changes for T3.
>
> > > > > - Dave Lypka.
>
> > > > > On Jul 25, 9:03 am, mdipierro  wrote:
>
> > > > > > Keep us posted. It would be great if you could post and be the
> > > > > > maintainer of a web2py openid app.
>
> > > > > > Massimo
>
> > > > > > On Jul 25, 6:49 am, dlypka  wrote:
>
> > > > > > > Hi:
>
> > > > > > > I triedhttp://w2popenid.appspot.com/oidconsumer
>
> > > > > > > It is amazing to see the web2py Admin page up on the App Engine.
>
> > > > > > > A few results:
>
> > > > > > > 1. dly...@gmail.com does NOT work.
> > > > > > >    I (and my associates) want the standard email address to work. 
> > > > > > > The
> > > > > > > URL Open ID is too clunky for most people we deal with.
>
> > > > > > > 2. I tried a URL version of my OpenID, which is
>
> > > > > > >        http://openid-provider.appspot.com/dlypka
>
> > > > > > >    That got me to the Open ID page, but it asked me to first log 
> > > > > > > into
> > > > > > > Google, which I believe is wrong, since I am already logged in to 
> > > > > > > this
> > > > > > > web2py forum.
>
> > > > > > >    So I conclude that the API is working great from web2py on GAE 
> > > > > > >  to
> > > > > > > OpenID, but it would be nice to have it recognize that I am 
> > > > > > > already
> > > > > > > logged into Google.
> > > > > > >    However I went ahead and did the Google login that it was 
> > > > > > > asking
> > > > > > > for, and then I did the the Yes response and it then gave me that 
> > > > > > > page
> > > > > > > with
> > > > > > >    the response codes:
>
> > > > > > > resp    :        > > > > > > id='http://openid-
> > > > > > > provider.appspot.com/dlypka' signed=['openid.return_to',
> > > > > > > 'openid.mode', 'openid.identity', 'openid.sreg.nickname']>
> > > > > > > admin request session response
>
> > > > > > > That was great!
>
> > > > > > > Then I closed the browser and went back in to try it all a second
> > > > > > > time, and this time it did NOT ask me to 

[web2py:27738] Re: Can I use HTTP PUT method?

[suiato]

CouchDB seems to support PUT.

--
Teru

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27739] Re: Can I use HTTP PUT method?

[Bottiger]

You will need to do request.body.read() for PUT. Web2Py does not parse
the body of PUT requests.

Example:

Request:

PUT /test/default/ HTTP/1.1
Content-Length: 21

blah blah hello hello


Output:

Body
"blah blah hello hello"

On Jul 31, 12:28 am, 诚子  wrote:
> Hi, I wan't use PUT method and DELETE method,to build a RESTful
> service,how to get an PUT method and DELETE data?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27740] Re: Table reference question

[Alastair Medford]

Thanks for the responses.

> db.student.student_id.requires=IS_NOT_IN_DB(db,'student.student_id')
> db.tasks.student.requires=IS_IN_DB(db,'student.id','%(student_id)s')
> db.tasks.student.represent=lambda id: db.student[id].student_id

This seems to accomplish what I was trying to do, thanks. However, I'm
in the dark as to what some of the syntax is. In the second line, I
know that the third argument has something to do with how the drop
down box chooses it's contents, but I do not understand the syntax of
'%(student_id)s'. Also, in the 3rd line I do not know what "lambda id:
" is doing. If this is standard python fare, then I apologise as I'm
still learning python and all it's syntax tricks. Thanks again.

Also sorry massimo is you see this twice, I think I hit reply to
author instead of reply.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27741] Re: Default CRYPT() is unsecure

[Brian M]

Pardon me for jumping in here, but I thought I'd try my hand at
putting this into some concrete examples.

Let's say we have an overly simple site with just three users (Jane,
Dick and Sally) and for some odd reason have made it a policy that
they can only choose from three passwords: "password", "secret" and
"hello". We'll say that our users have chosen the following passwords:
ID: username: password
1: Jane: hello
2: Dick: password
3: Sally: secret

Now we choose two different hashing methods.

Method #1 we take the password and "salt" it by adding the reverse of
the password so
 password_hash = hash(password+password[::-1])

and end up with hashes of:

Jane: 12DK789P
Dick: 486KX0AO
Sally: TY98B7C

A hacker somehow manages to steal our user table and gets our app
source so they know our salting and hashing methods. He simply runs
for password in ["password", "secret", "hello"]:
password_hash = hash(password+password[::-1])

and in three iteration has the password of all three users. In fact
even if we have 1,000 users Evil Hacker still got all 1,000 user's
passwords in only 3 iterations.

Method #2 we take the password and salt it by adding in the user's id,
so:
password_hash = hash(password + user.id)

Now Mr Evil Hacker again manages to gain access to our database and
app source. Again he tries to figure out our user's passwords. He
starts out with Jane
for password in ["password", "secret", "hello"]:
password_hash = hash(password+user.id) #user.id in this case
is "1"

Just as before after at most three iterations the password has been
figured out. BUT unlike with method #1 Evil Hacker only has Jane's
password and not Dick or Sally's. To get both Dick and Sally's
password it will take up to 6 more iterations for a total of 9 (3
times more than required if we use method #1). For each additional
user it takes another 3 passes (assuming the correct password is
always the last one we try).  So our 1,000 user database now took
3,000 tries vs 3 - that's a huge improvement overall.

The thing is for any single user, it only takes 3 tries with either
method. BUT to get everyone's password it takes n*3 tries.  Up the
complexity and say that our users can pick from any current English
words in the Oxford English dictionary, Method #1 only takes at most
171,476 tries while #2 takes n*171476 tries. Then let your users pick
from upper & lower case letters, numbers 0-9 and common symbols giving
96 possibilities total and require 8 characters and there are now 7.2
Quadrillion possibilities! Sure the hacker can bother to generate (or
obtain) a rainbow table for all the possibilities - if we used Method
#1 they now have the password for every single user.  Switch over to
Method #2 and even with those 7.2 Quadrillion hashes in their rainbow
table Mr. Hacker only got one of our say 1,000 user's passwords - they
need to generate 1,000 more rainbow tables to get everyone's!. We'll
assume that our chosen hashing method means that there aren't any
readily available rainbow tables so our hacker needs to generate his
own rainbow tables. Check out http://www.lockdown.co.uk/?pg=combi&s=articles
to see just how long that'll take him (at best if he's got a
supercomputer It'll take 83.5 days *per user* - reality probably a few
years). Unless you've got something really, really valuable the random
hacker just isn't going to bother.

So there is deterministic vs random salting (we'll claim user ID is
basically random - it doesn't matter since it's clearly stored in the
database anyway).

Now since either way the hacker needed to somehow compromise our
database does all this really matter all that much? Which, for most
sites, is going to be more interesting - the user's passwords or all
of the other data probably stored in the clear in the other database
tables? If it's e-commerce or something then maybe the passwords are
useful, for most other things who cares, I can just read all the
user's "private" password protected data without having to worry about
figuring out their password beforehand.

Hope that clears things up a little.

~Brian

On Jul 31, 3:12 pm, Jonathan Lundell  wrote:
> On Jul 31, 2009, at 12:56 PM, Julio wrote:
>
>
>
> >> If we have a deterministic (1:1) transform t() of the password, then
> >> hash(t(password)) is exactly some hash'(password). We've redefined  
> >> the
> >> hash function, and all we have to do is to create a new rainbow table
> >> for that function. That is, you can consider any 1:1 pre-hash
> >> transform of the password to be part of the hash function itself.
> >> Sure, if hash() was md5(), then hash'() will be something else, and
> >> you won't be able to take advantage of public rainbow tables. But you
> >> can create your own rainbow table for hash'.
>
> > I think here is where the source of confusion is, for the record I am
> > not talking a brute force known hash attack (which incidentally the
> > "random" salt used in your approach become "known" anyway).
>

[web2py:27742] Re: Default CRYPT() is unsecure

[Francisco Gama]

On Jul 31, 6:26 am, Bottiger  wrote:
> > That may not be a good idea, I think. That makes your password longer but 
> > with a possible cryptographic weakness because it's following a known 
> > generation rule (being formed by a string repeated 3 times).
>
> The primary concern is a precomputed rainbow hash table.
>

I know, but a brute force attack becomes more achievable using a rule
like that because you are introducing a lot of restrictions to the
possible passwords domain.
I give you an example, if you have a 32 bytes field for the password
and you generate passwords according to that rule, the attacker will
know in advance that he doesn't need to try passwords with a length
higher than 32 / 3 bytes, he also doesn't need to try passwords that
are smaller than the minimum allowed size by the application * 3 and
he can reject in advance all passwords that aren't formed by a
triplication of a substring.

I would say that for serious applications just use other algorithm
such as SHA-1.

> Anything related to password generation strength depends on the
> person's original password and even a random salt does not help,
> because if the database is compromised, then the attack knows which
> salt to generate hashes for. Therefore there really isn't anything
> wrong with just doubling or tripling the password as a salt.
>
> In fact, many websites such as Reddit (which I examined the source
> code) does this.
>
> On Jul 30, 9:51 pm, Francisco Gama  wrote:
>
>
>
> > On Jul 31, 5:16 am, Bottiger  wrote:
>
> > > As long as the salt is different for every password, it pretty much
> > > makes it infeasible for someone to create a large enough rainbow hash
> > > table attack.
>
> > > The Unix salt of 12 random bytes is ok, but comes at the cost of extra
> > > storage and pretty much the same benefit. To put a larger barrier on
> > > computational speed, you could double or triple the original password
> > > before putting it through the hash.
>
> > That may not be a good idea, I think. That makes your password longer
> > but with a possible cryptographic weakness because it's following a
> > known generation rule (being formed by a string repeated 3 times).
> > That makes the diversity of possible passwords much smaller which
> > isn't a good password policy.
>
> > Besides, the complexity is the same (which is close to say that the
> > computational speed is also close) and an attacker would need the same
> > number of attempts to break the password by brute force because all he
> > had to for each attempt X, the attempt XXX. He doesn't need to try X
> > or XX.
>
> > > On Jul 30, 8:38 pm, Jonathan Lundell  wrote:
>
> > > > On Jul 30, 2009, at 8:30 PM, Bottiger wrote:
>
> > > > > I know you have the mantra of not breaking backwards compatibility,
> > > > > but it is a pretty bad idea to have unsalted MD5 passwords.
>
> > > > > For example, let's say your password is "massimo". The MD5 hash of
> > > > > that happens to be "8cac5ac44b51f182143a43c4cdb6c4ac".
>
> > > > > Even forgetting rainbow tables, you can simply do a search for it on
> > > > > Google and you have 10+ pages telling you that it is the hash for
> > > > > "massimo".
>
> > > > How about a new validator that does the right thing, and deprecating  
> > > > CRYPT?
>
> > > > I'd prefer some less-predictable salt than the suggestion below,  
> > > > though. How about the old Unix passwd trick of choosing a some random  
> > > > salt, and appending the salt in plaintext to the hash?
>
> > > > >http://www.google.com/search?q=8cac5ac44b51f182143a43c4cdb6c4ac
>
> > > > > On Jul 30, 8:10 pm, mdipierro  wrote:
> > > > >> We cannot break backward compatibility. People should specify a key
> > > > >> and use the HMAC+SHA512 anyway.
>
> > > > >> Massimo
>
> > > > >> On Jul 30, 9:49 pm, Bottiger  wrote:
>
> > > > >>> The CRYPT validator is unsecure because it uses unsalted MD5.
>
> > > > >>> There are public rainbow tables that have unsalted MD5 passwords  
> > > > >>> of up
> > > > >>> to 10 characters long including symbols.
>
> > > > >>> I highly recommend that if no "key" is specified, that CRYPT will
> > > > >>> automatically salt the password based on a substring of the password
> > > > >>> itself. For example:
>
> > > > >>> password = "secretpass"
> > > > >>> hash = md5(password+password[-1])
>
> > > > >>> This will of course break backward compatibility, but this is a real
> > > > >>> security vulnerability.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27743] Re: file downloading problem

[陶艺夫]

I got it works evetually.
Guess what was wrong? I had a wrong spelled word in the conf file! It had
taken my 2 hours away from my life :)

Thanks a lot. You are so cool...

2009/8/1 mdipierro 

>
> which browser are you using? can you try wget and/or other browsers?
>
> On Jul 30, 10:32 pm, 陶艺夫  wrote:
> > Hi,
> > I'm using "response.stream(file_name)" method to offer users downloading
> > files which are sort of business-classified, but the downloading process
> > always terminated halfway. The testing file is 4.2M, an Excel workbook.
> > Is there anything I can do with system configuration(CherryPy), or  it's
> > just an internet problem?
> >
> > thanks
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27744] Re: file downloading problem

[陶艺夫]

Now there are some problems I can't figure out why.

My application has been doing well under binary web2py with cherrypy. After
I moved it into Apache and mod_wsgi env, some pages would issue an error
ticket and when I click the ticket link, it would continue issue another
error ticket, and on...
I found the admin application wouldn't work in this env till now. I try to
remove ssl from Apache, the error was still there.

Any idea?

2009/8/1 陶艺夫 

> I got it works evetually.
> Guess what was wrong? I had a wrong spelled word in the conf file! It had
> taken my 2 hours away from my life :)
>
> Thanks a lot. You are so cool...
>
> 2009/8/1 mdipierro 
>
>
>> which browser are you using? can you try wget and/or other browsers?
>>
>> On Jul 30, 10:32 pm, 陶艺夫  wrote:
>> > Hi,
>> > I'm using "response.stream(file_name)" method to offer users downloading
>> > files which are sort of business-classified, but the downloading process
>> > always terminated halfway. The testing file is 4.2M, an Excel workbook.
>> > Is there anything I can do with system configuration(CherryPy), or  it's
>> > just an internet problem?
>> >
>> > thanks
>> >>
>>
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27745] Re: Default CRYPT() is unsecure

[Bottiger]

I wrote before that I would not say anything about this anymore, but
having this thread pop up multiple times presented itself as a
persistent itch.

First of all I would like to apologize if I came off before as a
little abrasive. Second of all, I will not disagree that overall,
using a random salt is theoretically more secure. However, the other
method does not change the status quo much (no new db columns
something I believe Massimo values), at the cost of non-maximal
security.

Now I will address the issues that seem to be the cause of much
debate.

1. Attackers are only interested in 1 of the passwords.

If you have observed hacklogs, you will see that the only password the
hacker is interested in is the admin or root user. Why? Because it is
the one that is most likely to be the same as the computer the website
is hosted on. The hacker does not care about the other user passwords.
He already has the entire database and can play with everyone else's
accounts on the website. The only thing that could extract more value
is the possible connection that the root/admin account may be the same
as the host. (I can already hear you saying what if other people use
the same password as their email, but this doesn't happen as often as
you think and usually disposable or fake emails are used).

So what is the consequence of this? That hackers will use their
publicly precomputed unsalted rainbow tables to hack 1 account.
Therefore we should consider the case where a rainbow table attacks 1
password, not a collection.

2. Attackers will specifically target Web2Py's deterministic algorithm
with a custom rainbow table.

This is a possibility, but it is not a big one. First of all, even
with md5, generating tables is not something the average script kiddie
can do. It is only with the recent growth of public distributed
rainbow tables that you are seeing much more of these kinds of
attacks. Even a website as popular as Reddit has been using a salt
dependent on the password, and so far there have not seen any rainbow
tables specifically for their hash variant.

For script kiddies, lack of public rainbow tables for your variant
will lock them out.
For serious hackers, they only care about the admin account anyway.
And they have the resources to mount a single salted attack on it,
which means that a randomized salt is equivalent to a deterministic
salt.

So what is the consequence of this? That the script kiddies that would
be interested in compromising the other accounts besides root are
unable to do so, and the serious hackers would not waste their time on
a single variant, and would instead attempt to crack the admin/root
account.

When you consider these circumstances, it makes sense to consider that
the deterministic salt is equivalent to a random salt. The purpose of
the deterministic salt that I proposed was to eliminate the weakness
of a public rainbow table attack without the need to alter the schema
of the table or specifying a specific key.This was a vast improvement
over the current default without a change in the database. I was also
going to suggest using the user.id as a salt as someone else
mentioned, but that may depend on several possible problems such as
people changing their id, or id's being deleted, and then having the
database reinserted with different ids.


On Jul 31, 9:09 pm, Francisco Gama  wrote:
> On Jul 31, 6:26 am, Bottiger  wrote:
>
> > > That may not be a good idea, I think. That makes your password longer but 
> > > with a possible cryptographic weakness because it's following a known 
> > > generation rule (being formed by a string repeated 3 times).
>
> > The primary concern is a precomputed rainbow hash table.
>
> I know, but a brute force attack becomes more achievable using a rule
> like that because you are introducing a lot of restrictions to the
> possible passwords domain.
> I give you an example, if you have a 32 bytes field for the password
> and you generate passwords according to that rule, the attacker will
> know in advance that he doesn't need to try passwords with a length
> higher than 32 / 3 bytes, he also doesn't need to try passwords that
> are smaller than the minimum allowed size by the application * 3 and
> he can reject in advance all passwords that aren't formed by a
> triplication of a substring.
>
> I would say that for serious applications just use other algorithm
> such as SHA-1.
>
> > Anything related to password generation strength depends on the
> > person's original password and even a random salt does not help,
> > because if the database is compromised, then the attack knows which
> > salt to generate hashes for. Therefore there really isn't anything
> > wrong with just doubling or tripling the password as a salt.
>
> > In fact, many websites such as Reddit (which I examined the source
> > code) does this.
>
> > On Jul 30, 9:51 pm, Francisco Gama  wrote:
>
> > > On Jul 31, 5:16 am, Bottiger  wrote:
>
> > > > As long as the salt is different for every p

[web2py:27746] Re: Default CRYPT() is unsecure

[Jonathan Lundell]

On Jul 31, 2009, at 11:11 PM, Bottiger wrote:

> 2. Attackers will specifically target Web2Py's deterministic algorithm
> with a custom rainbow table.
>
> This is a possibility, but it is not a big one. First of all, even
> with md5, generating tables is not something the average script kiddie
> can do.

Google: rainbow table generator kit

http://www.google.com/search?hl=en&safe=off&q=rainbow+table+generator+kit&aq=f&oq=&aqi=

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27747] Re: Default CRYPT() is unsecure

[Bottiger]

Yes the software is there, but the hardware is a completely different
matter.

On Jul 31, 11:15 pm, Jonathan Lundell  wrote:
> On Jul 31, 2009, at 11:11 PM, Bottiger wrote:
>
> > 2. Attackers will specifically target Web2Py's deterministic algorithm
> > with a custom rainbow table.
>
> > This is a possibility, but it is not a big one. First of all, even
> > with md5, generating tables is not something the average script kiddie
> > can do.
>
> Google: rainbow table generator kit
>
> http://www.google.com/search?hl=en&safe=off&q=rainbow+table+generator...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---

[web2py:27748] Re: Default CRYPT() is unsecure

[Bottiger]

Also, I just downloaded winrtgen, the one that is displayed all over
your google results.

No ability for specifying a salt, or even a custom salting function.

On Jul 31, 11:15 pm, Jonathan Lundell  wrote:
> On Jul 31, 2009, at 11:11 PM, Bottiger wrote:
>
> > 2. Attackers will specifically target Web2Py's deterministic algorithm
> > with a custom rainbow table.
>
> > This is a possibility, but it is not a big one. First of all, even
> > with md5, generating tables is not something the average script kiddie
> > can do.
>
> Google: rainbow table generator kit
>
> http://www.google.com/search?hl=en&safe=off&q=rainbow+table+generator...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~--~~~~--~~--~--~---