Re: A Letter to the Authors of Web Authentication Libraries
On Sat, May 2, 2009 at 11:27 PM, Paul Johnston wrote: > However, the use of JavaScript MD5 is not widespread. I think this is > because few authentication libraries support it. It is possible for a > library to provide JavaScript MD5 as an authentication mechanism, with > the details hidden from the application developer. In fact, it's quite > easy to implement, and there is a lot of guidance on my site. I think it is not widespread because it is not in any way whatsoever an improvement when compared to sending credentials in the clear over a non-secure connection. The only options are SSL or more complicated protocols which do not use the transmission of a single password or password-like credential. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: A Letter to the Authors of Web Authentication Libraries
Is there a fallback to normal auth possible if js is not running? I like the idea, but preventing someone who doesn't have js enabled to register/auth is pretty harsh. On Sun, May 3, 2009 at 6:27 AM, Paul Johnston wrote: > > Hi, > > Many web sites have a user name and password login system, and do not > use SSL. As a consequence, users' passwords are transmitted over the > internet unencrypted. This puts them at risk, particularly if the user > is on a shared ethernet segment, or open wireless network. > > For many years I have provided a JavaScript MD5 library (http:// > pajhome.org.uk/crypt/md5/), which can be used to perform a challenge- > response login. This avoids passwords being transmitted unencrypted, > although the security is not as strong as SSL. A number of web sites > currently use this technique; for some years Yahoo did, although they > now have SSL login. > > However, the use of JavaScript MD5 is not widespread. I think this is > because few authentication libraries support it. It is possible for a > library to provide JavaScript MD5 as an authentication mechanism, with > the details hidden from the application developer. In fact, it's quite > easy to implement, and there is a lot of guidance on my site. > > So, this is a call to the authors of all web authentication libraries. > Add JavaScript MD5 as an authentication mechanism. And then let me > know, so I can link to you from my site. If you need any help > implementing it, drop me a line, I'll do what I can. > > I think supporting this mode would be a big selling point for any > authentication library. And if support becomes widespread, the > internet becomes a little bit safer for everyone. > > Best wishes, > > Paul > > > > -- Adys --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
A Letter to the Authors of Web Authentication Libraries
Hi, Many web sites have a user name and password login system, and do not use SSL. As a consequence, users' passwords are transmitted over the internet unencrypted. This puts them at risk, particularly if the user is on a shared ethernet segment, or open wireless network. For many years I have provided a JavaScript MD5 library (http:// pajhome.org.uk/crypt/md5/), which can be used to perform a challenge- response login. This avoids passwords being transmitted unencrypted, although the security is not as strong as SSL. A number of web sites currently use this technique; for some years Yahoo did, although they now have SSL login. However, the use of JavaScript MD5 is not widespread. I think this is because few authentication libraries support it. It is possible for a library to provide JavaScript MD5 as an authentication mechanism, with the details hidden from the application developer. In fact, it's quite easy to implement, and there is a lot of guidance on my site. So, this is a call to the authors of all web authentication libraries. Add JavaScript MD5 as an authentication mechanism. And then let me know, so I can link to you from my site. If you need any help implementing it, drop me a line, I'll do what I can. I think supporting this mode would be a big selling point for any authentication library. And if support becomes widespread, the internet becomes a little bit safer for everyone. Best wishes, Paul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: dict over DSN; mixing bound/unbound fields; ManyToMany for create view
On Sat, 2009-05-02 at 08:29 -0700, ken keller wrote: [...] > I'm interested in hearing how you cope w/ the problem of specifying > ManyToMany relationships in an object creation view. Consider two > models M1 & M2 and a creation view/form for M1. A technique I'm using > is to specify M2 values as an unbound field in a ModelForm for M1. > When the form validates: > m1Form.save() > I convert m1Form['m2'] into ManyToMany relationship chgs. This works > but it defeats the purpose of ModelForm. > > I'm making use of a scrolling of checkboxes instead of a shuttle > widget (takes up too much space) or a multi-select widget (easy to > mess up the selection). I'm considering creating a custom widget for > the MultipleChoiceField. Is this practical or a good idea? The two questions here are probably best raised on the django-users list. This list (django-developers) is for internal Django development. Questions about using Django are the area of django-users and we try very hard to keep the two separate, as there's a vast difference in audience, volume and content. Thanks for you understanding on this. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
dict over DSN; mixing bound/unbound fields; ManyToMany for create view
I'm new to this list so sorry if this post is perceived as spam. Multi-DB: I prefer dict to DSN because it raises the abstraction beyond cryptic syntax. It is great that django allows mixing bound/unbound fields in a ModelForm. I'm using an unbound field as a CAPTCHA. I'm interested in hearing how you cope w/ the problem of specifying ManyToMany relationships in an object creation view. Consider two models M1 & M2 and a creation view/form for M1. A technique I'm using is to specify M2 values as an unbound field in a ModelForm for M1. When the form validates: m1Form.save() I convert m1Form['m2'] into ManyToMany relationship chgs. This works but it defeats the purpose of ModelForm. I'm making use of a scrolling of checkboxes instead of a shuttle widget (takes up too much space) or a multi-select widget (easy to mess up the selection). I'm considering creating a custom widget for the MultipleChoiceField. Is this practical or a good idea? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multi-DB Update
On May 2, 12:19 am, Malcolm Tredinnick wrote: > I'd prefer dictionaries to strings, because strings are tough to modify > dynamically -- as has already been demonstrated a few times in Django's > history. That's a pretty strong argument in favour of dictionaries - in which case it might be good to switch the CACHE_BACKEND setting over to using dictionaries instead of a DSN-style string at some point in the future - consistency seems like it would be a good thing here. Cheers, Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
