you are right if you want to protect against the attack itself only. if you want to have the benefit of the "no-stored-password" as well then you have to randomize the field names as well. if you take hashes that you can reproduce predictable (no need for storage in session) or if you take a session based approach is then up to you.
cheers lenz On Tue, Apr 14, 2009 at 11:01 AM, <[email protected]> wrote: > > At the risk of moving off topic slightly - but in the interests of > discussing programing practices - > I would have thought that merely one randomised (not hashed) identifier as > an "embedded cookie" is sufficient against such an attack. (Hashes are not > nil semantics). > As field names should always occupy a unique namespace anyway, as opposed > to internal > variable names or (heaven forbid) database names, then to my way of > thinking the nil semantic solution (and easier to impliment) would be to > anonymise fields as 1, 2, 3. > I mean this kind of thing for forms: > > form name="form1" > input type="hidden" name="f0" value="GYHyj456HgRF" > input type="text" name="f1" > input type="text" name="f2" > input type="submit" value="login" > /form > > I would suggest that only reason that programmers put anything semantic on > forms > is lazy practices when it comes to maintaining a public namespace. > Keith > > > On Tue, 14 Apr 2009 09:31:00 +1200, lenz <[email protected]> wrote: > > hi, > > a bit more tricky but helps for sure. set the field names to hashes that > > you > > store in a matching table in the session and recompute every time you > > generate the form. more hassle but also protects against scripting the > > login > > form (what i used it for). > > > > cheers > > lenz > > > > On Tue, Apr 14, 2009 at 9:25 AM, S.Mohammed Alsharaf > > <[email protected]>wrote: > > > >> hi > >> > >> after the submition if there is error fill username field with the > > username > >> but for the password word fields fill it with nothing. > >> > >> thats what i do and it works fine. > >> > >> if browser still showing the data then try to clear cache or redirect > > user > >> to the page on error with header();. error message can be saved in > > session > >> or url query > >> > >> hope this helps > >> Mohammed Alsharaf > >> http://www.safitech.com > >> > >> > >> > Date: Tue, 14 Apr 2009 09:17:12 +1200 > >> > Subject: [phpug] How to control "Save password" functinality of > > browser > >> on a change password screen > >> > From: [email protected] > >> > To: [email protected] > >> > >> > > >> > > >> > Hi, > >> > > >> > I think I have the following problem with a change password/upgrade > >> > password screen: > >> > > >> > - User enters his username, old password and two copies of a new > >> > password, submits > >> > - Browser appears to save the new password > >> > - System rejects new password due to quality,i.e. too short > >> > - System shows form again, however now browser fills out old password > >> > field with new - wrong- password > >> > - User types in better password, but now gets rejected because of > >> > wrong "old" password > >> > > >> > Can I control the password remember functionality of common browsers > >> > here? Any workaround? > >> > > >> > > >> > Kind Regards, > >> > > >> > Jochen Daum > >> > > >> > Chief Automation Officer > >> > Automatem Ltd > >> > > >> > Phone: 09 630 3425 > >> > Mobile: 021 567 853 > >> > Email: [email protected] > >> > Skype: jochendaum > >> > Website: www.automatem.co.nz > >> > > >> > > > >> > > > > > > -- > > iWantMyName.com > > painless domain registration (finally) > > > > > > > > -- iWantMyName.com painless domain registration (finally) --~--~---------~--~----~------------~-------~--~----~ NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected] -~----------~----~----~----~------~----~------~--~---
