> On Wed, Apr 20, 2016 at 4:16 PM, Arun S <arun....@gmail.com> wrote: > > > let me try to clear my question. > > > > please correct me if am wrong. > > basically all I want to know is that there already exists a number of > > Unicode normalization forms. > > Reference > > > > Unicode normalization forms: http://unicode.org/reports/tr15/#Norm_Forms > > > > so as I said as a part of a company norms, the project needs to follow > > certain csdl standards and according to that it states that all passwords > > shall be normalised according to the ref mentioned and then convert then to > > a utf8 which then follows thru the hashing process. > > > > so since the major part of the project uses djangos frameworks, I believe > > that the user authentication methods used already applies the hashing > > algorithms. > > > > but what I could not figure out is that > > 1: does django apply any such normalization process for the user passwords. > > 2: how is it different between a normalised password and then hashed with > > djangos hashing algorithm s and a non normalised password just saved after > > hashing.
Ah, unicode normalization, now your question makes a lot more sense. A quick grep through the sources of Django didn't reveal any explicit normalization of plaintext passwords. However, you can implement your own hashing function that will use the unicodedata module from the standard library to perform unicode normalization, and then call one of the built-in password hashers to do the actual work. On Wed, Apr 20, 2016 at 04:20:35PM +0300, Avraham Serour wrote: > in summary: "Unicode Normalization Forms are formally defined > normalizations of Unicode strings which make it possible to determine > whether any two Unicode strings are equivalent to each other" > > as I see this would be highly unsecure for passwords, this is something > like converting special characters to latin characters, or forcing lower > case only I don't agree – when a user enters the letter Å, you almost never care wheher it is represented as U+00C5, or U+0041 U+030A – they represent the same character, just in two different ways. Unicode normalization is a tool to recognize those two representations as the same thing. As a user, if I use a password containing non-ASCII characters, I definitely wouldn't expect that with the same correct password, I would be able to authenticate using a browser that sends the data in a composed normal form, but not with another browser that sends the same string in a decomposed normal form. Regards, Michal -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/20160420134232.GF1129%40koniiiik.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
