Password expiration

#1

I would like to have the user change their passwords every 90 days. Is
there a program within D3 that would look after this?

Would it be easier to add a new dictionary item within the users and do
a date comparison and have them change the password if greater than 90
days. Then the new date would have to be written out also.

Any ideas? Why would RD not do something to this effect? Has nobody
wanted D3 users to change their passwords?

Any help much appreciated.

#2

kim wrote:

Quote:

I would like to have the user change their passwords every 90 days. Is
there a program within D3 that would look after this?

If you're using D3/NT, the user logons can be tied to valid users for
your network.

You would need to update the registry key Pick0/UserLogon

’0’: Logon is prohibited

‘1’: User/password controlled only though the USERS file.

’2’: User/password is controlled by Windows NT. Note the VME must be
startted logged on as a user who has ‘act as the operating system’
privilege.

One of our clients that runs D3/NT wanted what you are after, but
didn't want to use the "UserLogon" option 2 as described above. In
this case, we rolled our own system.

Quote:

Would it be easier to add a new dictionary item within the users and
do a date comparison and have them change the password if greater
than 90 days. Then the new date would have to be written out also.

We did something like this, including logging old passwords so they
could not be used again.

You only need 4 simple programs:

1) A master maintenance program for an admin to set passwords and if
desired, create/delete users.

2) A subroutine to change passwords for a single user.

3) A program for users that calls the subroutine to change passwords.

4) A program to check for password expiration and call the subroutine
to change passwords if necessary. Put this in your logon proc.

It's a simple system that will work for most.

You can have the whole thing working in a couple of hours, if not less.

--
Kevin Powick

#3

We are using Redhat Linux ws3, we do not use linux users, they are
locked down to a specific port within D3.

#4

kim wrote:

Quote:

We are using Redhat Linux ws3, we do not use linux users, they are
locked down to a specific port within D3.

Here is a little program that tracks each when each user's password was
last updated and makes them change it periodically. At this site user
information is kept in the 'whos' file. The point is, it is not hard to
manage this stuff yourself.

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

------------------- basic begin ---------------------

Quote:

* logon process to maintain user passwords
* 04-19-94 asb
*
break off
prompt ""
*
$include es whos.fmcs
*
pmax = 60 ;* require new password every 60 days
tries = 0 ;* password attempts counter
tries.max = 3 ;* max attempts allowed
*
open "users" to users else stop 201,"users"
open "whos" to whos else stop 201,"WHOS"
*
call get.user.srt(user) ;* return user id e.g. oconv("u","u50bb")

* 12-08-03 asb: these are automatic processes...
ok = 1
begin case
case user eq "cpi"
case user eq "smdr"
case 1 ; ok = 0
end case
if ok then stop

read wrec from whos,user then
if wrec<whos.term.date.fmc> ne "" then
print " Sorry, ":user:" is not a valid employee??"
go 1000
end
end else
print " Sorry, ":user:" is not a valid employee??"
go 1000
end
*
read urec from users,user else
print " error! no USER record for ":user
go 1000
end
*
if urec<7> eq "" then pdays = 0 ; go 30 ;* require new password

pdate = wrec<whos.pdate.fmc
pdays = pmax - (date() - pdate) ;* days remaining for passwor
if pdays lt 0 then go 1000 ;* too late
if pdays gt 10 then go 999 ;* ok
*
xdate = oconv(pdays + date(),"D2-")
tries = 0
*
print char(7)
print " Your password will EXPIRE in "

days:" days (on ":xdate:")."
print " You must create a new password before then or you will not be able
*
30 *
*
tries = tries + 1
if tries gt tries.max then
print " ":tries.max:" tries are all you get."
go 1000
end
*
print
print " Enter NEW password: ":
echo off
input password
echo on
x = password
call pc.input.test(x)
if x eq "QUIT" then go 999
if x eq "" then
if pdays gt 0 then
go 999
end else
print " You must enter a NEW password now."
go 30
end
end
**if len(password) gt 8 then
** print " Sorry, but the maximum length of a password is 8 characters."
** go 30
**end

if len(password) lt "5" then
print "Password must be at least 5 characters."
go 30
end

ok = 0
if not(x matches "0n") then
if not(x matches "0a") then
ok = 1
end
end

if ok else
print "Password must include both letters and numbers."
go 30
end

if oconv(password,"U3060") eq urec<7> then
print " You must enter a NEW password."
go 30
end
*
print
print " Re-enter password to confirm: ":
echo off
input confirm
echo on
x = confirm
call pc.input.test(x)
if x eq "QUIT" or x eq "" then go 30
*
if confirm ne password then
print "Sorry, incorrect password entered??"
go 30
end else
call pc.readu(x,users,user,0,err,0)
call pass.test.sub(user,password)
writev oconv(password,'U3060') on users,user,7
call pc.readu(x,whos,user,0,err,0)
writev date() on whos,user,whos.pdate.fmc
print
print " Password updated."
end
*
*
999 * normal exit
*
break on
stop
*
1000 * error exit
*
chain "OFF"

#5

kim wrote:

Quote:

We are using Redhat Linux ws3, we do not use linux users, they are
locked down to a specific port within D3.

Ok.

Well, you didn't mention that in your original post.

Then use the other option I gave you. Write it yourself.

It's should be quite trivial.

--
Kevin Powick

#6

"Why would RD not do something to this effect?"

ROFL !!

#7

"kim" wrote:

Quote:

Why would RD not do something to this effect?

Good answers have already been provided for your password question.
I'll just respond to this one.

Kim, one of the beauties of the Pick environment is that it is so easy
to customize. The native environment does not include every possible
feature because everyone will have a different opinion of how features
should be implemented, so any "one size fits all" solution is bound to
be wrong for someone, and someone eventually says "are they stupid?
why did they do it like that?"

Some core functions are provided by the vendors along with source code
as a working suggestion for how most sites might like things to work -
if you don't like it, the code may be there and you can change it.
Look in dm,bp, and you'll see what I mean. (As we've discussed in
this forum, this code is not "Open Source Software". The code is open
for you to view and change, but it is copywritten and cannot legally
be moved to other environments or modified/sold as one's own product.
OpenQM is the most open environment in our market, completely and
truly Open Source Software.) Source is not available for some
routines where the vendor prefers that everyone do things in a
consistent manner. Be careful though, as with Linux and other Open
Source software, responsibilities are inherent when someone starts
tweaking source code; when the vendor updates _their_ code (because it
is theirs to modify) and fixes bugs, your code may get over-written,
and you may want to roll their changes into your own code.

In my opinion the DBMS vendors should continue to do what they can to
ensure that we have the core tools required to do things that we want,
but they should not over-do the effort on things that we can do for
ourselves. Other people differ in their opinions about where this
line is drawn. In the Linux community, one group works on the kernel,
others work on libraries above that, and others bundle those libs and
packages into distros - people expect this division of
responsibilities. People get very angry when Microsoft attempts to
put too much application-level functionality into Windows, especially
when they do it badly. But the same user/developers who expect to see
clear lines between the core operating system and higher level
packages expect many package-level features to be built into their
DBMS. In our market many people expect the MV DBMS vendors to do all
of this, but I disagree. I want the database to work and I want a
fully functional BASIC compiler and debugger - because I'm not
qualified to work on those things myself. But a password maintenance
routine or backup routine or job scheduler? These things we can do on
our own and we can give or sell them in our community as we see fit.

So please keep these things in mind when you wonder about how
something was implemented or why it was or was not implemented. And
if you have any questions about whether something is actually in there
or not, or how to do something, please feel free to ask us.

Good luck
Tony
TG@ removethisNebula-RnD.com

#8

I've long had the gut feeling that requiring frequent (*) password
changes of users was actually counter-productive to security. Those who
feel strongly about this (agreeing or disagreeing) might find Gene
Spafford's recent and much-discussed blog posting of interest:

Security Myths and Passwords
http://www.cerias.purdue.edu/weblogs...neral/post-30/

/jdr/

(*) I'm not saying forced changes every 90 days are necessarily
"frequent" - some places I've been are far, far more Draconian in their
policies than that.

#9

I think the primary reasoning behind the requirement that passwords be
changed every NN days is concern that if a password is compromised, the
exposure is limited to NN days. This is probably based on the
presumption that a compromised password was accidently "exposed" rather
than "disclosed" (to use Spafford's terminology).

But overall, I think you are right: requiring frequent password changes
likely increases the probability that users will write them down
somewhere (if they didn't choose a new *easy to remember* password), and
thus more easily found or discovered.

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

David Ruggiero wrote:

Quote:

I've long had the gut feeling that requiring frequent (*) password
changes of users was actually counter-productive to security. Those who
feel strongly about this (agreeing or disagreeing) might find Gene
Spafford's recent and much-discussed blog posting of interest:

Security Myths and Passwords
http://www.cerias.purdue.edu/weblogs...neral/post-30/

/jdr/

(*) I'm not saying forced changes every 90 days are necessarily
"frequent" - some places I've been are far, far more Draconian in their
policies than that.

#10

Hi
Passwords are the bane of my life for the reasons you all state. However we
can all thank that pair of wretches Sarbanes & Oxley for this frequent
change codswallop becoming a major nuisance. Anyone who has to deal with
the auditors of major US companies will find this mantra "passwords must be
changed every x days" at the head of their checklist. Unfortunately they do
not examine the underlying strength of a system's internal audit controls
which are far more important.
Net result people forget them or write them down. In fact the best set I
ever saw was at a recent auction of a significant number of terminals every
item had a Post-It note stuck on it dirty and peeling showing its age with
the users passwords updated as they changed.
Peter McMurray
"Scott Ballinger" <scott (AT) TiredOfSpamButStillatPareto (DOT) net> wrote

Quote:

I think the primary reasoning behind the requirement that passwords be
changed every NN days is concern that if a password is compromised, the
exposure is limited to NN days. This is probably based on the
presumption that a compromised password was accidently "exposed" rather
than "disclosed" (to use Spafford's terminology).

But overall, I think you are right: requiring frequent password changes
likely increases the probability that users will write them down
somewhere (if they didn't choose a new *easy to remember* password), and
thus more easily found or discovered.

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

David Ruggiero wrote:
I've long had the gut feeling that requiring frequent (*) password
changes of users was actually counter-productive to security. Those who
feel strongly about this (agreeing or disagreeing) might find Gene
Spafford's recent and much-discussed blog posting of interest:

Security Myths and Passwords
http://www.cerias.purdue.edu/weblogs...neral/post-30/

/jdr/

(*) I'm not saying forced changes every 90 days are necessarily
"frequent" - some places I've been are far, far more Draconian in their
policies than that.