Change Password Forms - As They Should Be | Fri 8 Oct 2010 | Blog

Change Password Forms - As They Should BeFri 8 Oct 2010

Yesterday I knocked together a password management page for an ASP.NET web application I've been working on.

Nothing special. Just the kind of thing any average web user would expect of a website. Most importantly, that any password change is instant. As is access after an initial registration. More than can be said of Domino.

It was always with huge professional embarrassment that I found myself having to add messages to an already-hacked version of Domino's change password form that said something along the lines of:

Your password has been changed. While this may take effect immediately, please allow up to 24 hours for this change to take place. If you find yourself unable to use your new password straight-away please continue to use your old one until it stops working, at which point you should switch to your new one.

No, seriously, I had to add that to a Domino website! Lord knows what users who read it must have thought.

Now I know there are things you can try and do to help prevent the caching of passwords in Domino, but I don't really relish the idea of calling view refreshes on the address book or whatever it is you need to do. And it misses the point that I really shouldn't have to.

Part of me always thought this would get addressed in Domino at some point, but, unless I've missed something, it's just another aspect of Domino that's gone without attention for what must be 10+ years.

So, you can imagine how nice it felt yesterday to finally have the complete control I've always wanted over things like this. Sure, I had to create the Users table in SQL and create the registration process from scratch (things that using Domino means I don't have to do), but I'd happily spend a day of my time at no cost adding my own processes, just so I know I can make a website that works like it ought to.

Comments

- Paul
- Fri 8 Oct 2010 03:47 AM
Jake,
Have you looked into .net membership? Nearly everything you need with little effort to setup. Possibly overkill for a simple system though...

Reply
1. - Alyn R. Tiedtke
  - Fri 8 Oct 2010 05:18 AM
  Yep i'll back the .net Membership schema here. Very easy to implement, secure by default (all passwords etc are encrypted and salted etc.) and provides just about everything you need for a login screen etc.
  
  Reply
- Paul Mooney
- Fri 8 Oct 2010 04:44 AM
Hi Jake
Just so you know, you can change the password cache on the server so it takes place immediately (or when you wish)
HTTP_PWD_CHANGE_CACHE_HOURS=N

Reply
1. - Jake Howlett
  - Fri 8 Oct 2010 05:31 AM
  And N can be 0? And it works? Like, actually works?
  What about newly created Person documents from scripts - does the ini setting cover that?
  
  Reply
  
  Show the rest of this thread
  1. - Paul Mooney
    - Fri 8 Oct 2010 06:07 AM
    It works when set to 0. n=hours for cache. 0=no cache. I have seen it cause a few issues if you have custom change password forms (in fairness only seen it on one site).
    TBH I have no tested it on scripted setup. But it removes the password from the cache so it "should" work just fine.
    
    Reply
2. - Fredrik Stöckel
  - Sat 9 Oct 2010 04:32 PM
  Nice one, didn't know such existed, thanks!
  
  Reply
- Nathan T. Freeman
- Fri 8 Oct 2010 07:46 AM
"I don't really relish the idea of calling view refreshes on the address book or whatever it is you need to do."
Ummm... why not?

Reply
1. - Sagar
  - Fri 8 Oct 2010 09:34 AM
  1. because its more than 10 years and IBM failed to provide right solution to such basic and important issue.
  2. It may slow down for large views when you have continuous update to person documents such as in a public website where users can self register and manage their user profiles.
  
  Reply
  
  Show the rest of this thread
  1. - Erik Brooks
    - Fri 8 Oct 2010 07:54 PM
    So.... view.refresh() isn't the "right solution" but:
    "Sure, I had to create the Users table in SQL and create the registration process from scratch"
    is?
    Seriously... of all the things you can gripe about with Domino, security management is NOT one of them.
    
    Reply
    1. - Erik Brooks
      - Fri 8 Oct 2010 08:03 PM
      Oh, and since ND6.0+ each update task also spins off a directory indexer task. It's basically an update task that *only* watches names.nsf and other directories.
      So out-of-the-box (unless your server is ridiculously overloaded) the default update interval of 5 minutes will get your pw change every time anyway.
      
      Reply
  2. - Erik Brooks
    - Sat 9 Oct 2010 09:59 AM
    Pretty sure I typed this last night but it's gone now... so I'll retype:
    "but, unless I've missed something, it's just another aspect of Domino that's gone without attention for what must be 10+ years. "
    Jake, you did miss something. Since N/D 6.0, the update task spins off a "directory indexer" task which is another update task that ONLY watches names.nsf and other directories. So even out of the box a pw change takes whatever your update queue time is (5 minutes I believe is the default.)
    All you need is a view.refresh() call to force it to happen immediately. And if your NAB views are going to die from that, you've obviously got much bigger problems.
    This is all if you're modifying NAB documents directly. Paul's ini allows you to manage the timeframe over which the old and the new pw are both simultaneously active.
    Of all the things that we can gripe at IBM about with Domino, security administration is definitely not on the list. It's way out in front of every other platform out there, and that's without even discussing implementation of readers/authors fields.
    
    Reply
    1. - Erik Brooks
      - Sat 9 Oct 2010 10:03 AM
      Gah! I got bit by the "show the rest of this thread" button! I feel like such a n00b...
      To be fair though, the directory indexer change in ND6 didn't get anywhere near enough promotion in my opinion. That was a very simple yet huge improvement over the R5 days.
      
      Reply
    2. - RobShaver
      - Sat 9 Oct 2010 10:23 AM
      So which is the better wait time; five minutes or zero seconds? When it's zero (or at least updated before they try to log in) then it's fixed.
      Not to mention if you're using groups in the ACL. (I have a fully automated web-enabled group creation/maintenance infrastructure that I build and rely on for all my designs. It's one of the things that makes Notes/Domino so useful.)
      Add a new user to an ACL group and wait how long until they can have access? Anything longer that zero makes my customers ask why I can't do as good as their competition.
      So I doubt if I'll ever switch to .net but these issues have been with Notes since I've been using it. I deal with it but you can't make me like it! :)
      
      Reply
      1. Erik Brooks
        
        Sun 10 Oct 2010 09:21 AM
        
        "Not to mention if you're using groups in the ACL."
        That's another setting in the NAB. "Group cache refresh interval" if I recall. I think there's an INI for that also -- look for "NLCACHE" and you should be able to find it.
        So again, trivial fixes to the problem. But that is one of the "challenges" of N/D -- for backwards-compatibility reasons the out-of-the-box settings may not be ideal.
        Maybe I'll do a blog post about password changes.
        
        Reply
- Craig Boudreaux
- Fri 8 Oct 2010 09:29 AM
2 comments:
1) I have applications that have been doing the recommended view refresh thing for almost 10 years on the password change, and all has been fine. Will look into @Paul's password cache thing though.
2) You mean don't like doing things you shouldn't have to do more than having to do 'other' (more time intensive) things you shouldn't have to do? And is that application security you wrote in a day as secure as what Domino has out of the box?

Reply
- Aaron Hardin
- Fri 8 Oct 2010 10:33 AM
Hey Jake
I know that you are pretty busy now, but I would like to see how you build your controls with ASP or PHP. Just if you are looking for a new topic :)

Reply
- Ross Hawkins
- Fri 8 Oct 2010 09:43 PM
+1 for .NET membership btw - although personally the schema as it comes out of the box isn't to my liking, but it's easy to modify and create your own re-usable customised provider which will happily work with WebForms/MVC/whatever.
+1 as well for not enjoying telling Domino customers in the past "Wellllll you've changed your password, but it takes a while to update on the server.. why? Wellll....."

Reply
- Erwin
- Mon 11 Oct 2010 06:26 AM
Can you reassure me that your blog is not sponsored?
I totally agree with Craig Boudreaux.

Reply
1. - Jake Howlett
  - Mon 11 Oct 2010 07:40 AM
  Damn, I've been rumbled. This site has been sponsored by Microsoft all along. I can't believe it took 10 years for somebody to notice.
  
  Reply
  
  Show the rest of this thread
  1. - Aaron Hardin
    - Mon 11 Oct 2010 09:17 AM
    LOL - Jake says "NO!!! and it never will be; unless you're offering cash and prizes."
    
    Reply