This is G o o g l e's cache of http://www.lp.se/ftp/mailinglists/PWDCHG.1998-02.
G o o g l e's cache is the snapshot that we took of the page as we crawled the web.
The page may have changed since that time. Click here for the current page without highlighting.
Google is not affiliated with the authors of this page nor responsible for its content. |
| These search terms have been highlighted: | levitte | programming |
|
|
Archive-Date: Tue, 24 Feb 1998 15:18:37 +0100
From: thomasgd@omc.bt.co.uk (Greg Thomas)
Reply-To: PWDCHG@lp.se
To: PWDCHG@lp.se
Subject: Changing passwords
Date: Tue, 24 Feb 1998 14:18:24 GMT
Message-ID: <3500d3ec.330956640@www.omc.bt.co.uk>
References: <9790-Fri13Jun199716:13:35+0200-levitte@lp.se>
In-Reply-To: <9790-Fri13Jun199716:13:35+0200-levitte@lp.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Is this list still active? If so, I came across
http://webmaster.fccj.cc.fl.us/Webmaster/WebPass.html today - a Perl
CGI script that changes a users password for them. It calls expect,
which then calls the UNIX command 'passwd'. I've no idea if expect if
ported to OpenVMS, but as far as I can tell it could be trivially
replaced by remote tasking a small DCL procedure; something along the
lines of=20
$ ! WebPass.COM - OpenVMS equivalent of WebPass.expect
$ ! First draft, never even run, no error checking by Greg Thomas, =
24/02/1998
$ !
$ ! P1 - Username
$ ! P2 - Old Password
$ ! P3 - New Password
$ !
$ open/write F temp.com
$ write F "$ set password"
$ write F P2
$ write F P3
$ write F P3
$ close F
$ !
$ copy temp.com 0"''P1' ''P2'"::temp.com
$ delete temp.com;*
$ !
$ type 0"''P1' ''P2'"::"TASK=3DTEMP"
$ delete 0"''P1' ''P3'"::TEMP.COM;*
$ !
$ ! All done!
I don't have access to Perl ATM (and know next to nothing about it),
but perhaps someone else could take a look and advise on whether or
not the Perl script combined with some DCL based on the above
works? If it's any good, I might look at finally getting around to
installing Perl.
That's if anyone is out there, that is!
Greg
================================================================================
Archive-Date: Tue, 24 Feb 1998 15:27:44 +0100
Date: Tue, 24 Feb 1998 07:27:18 -0700
From: "Fitch, Randy" <Randy.Fitch@Coors.com>
Reply-To: PWDCHG@lp.se
Subject:
To: "'PWDCHG@lp.se'" <PWDCHG@lp.se>
Message-ID: <c=US%a=MCI%p=COORS%l=EARNESTT-980224142718Z-77338@earnestt.golden.coors.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
HELP
================================================================================
Archive-Date: Tue, 24 Feb 1998 19:38:23 +0100
Sender: ousap@msu.oscs.montana.edu
Date: Tue, 24 Feb 1998 11:38:03 MDT -0600
From: Allen Porter <ousap@msu.oscs.montana.edu>
Reply-To: PWDCHG@lp.se
To: PWDCHG@lp.se
Message-ID: <009C24A1.218C6F57.37@msu.oscs.montana.edu>
Subject: RE: Changing passwords
> Is this list still active?
Well, there is at least one of us out here.
>$ type 0"''P1' ''P2'"::"TASK=TEMP"
>$ delete 0"''P1' ''P3'"::TEMP.COM;*
I use a similar setup with DCL. I highly recommend DELETE/ERASE to
clean up the .COM files. I do the deletes on the remote end, but it
requires two files because a .COM file cannot DELETE/ERASE itself while
it is running.
The first command file does the actual password changing. The second
command file executes the first file, then DELETE/ERASEs it, and then
DELETEs itself.
A BIG CAVEAT:
I cannot get this to work on version 6.2 or higher of VMS because the
PASSWORD command will no longer read from the command stream. If anyone
knows how to do this, please post the answer.
Allen
================================================================================
Archive-Date: Tue, 24 Feb 1998 23:38:56 +0100
Date: Tue, 24 Feb 1998 17:27:46 -0500 (EST)
From: Eric <Eric.Rostetter@utoledo.edu>
Reply-To: PWDCHG@lp.se
Subject: Re: Changing passwords
To: PWDCHG@lp.se
Message-ID: <01ITYS7MW1GI003WVO@uoft02.utoledo.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
> > Is this list still active?
>
> Well, there is at least one of us out here.
Make that two... :)
> A BIG CAVEAT:
>
> I cannot get this to work on version 6.2 or higher of VMS because the
> PASSWORD command will no longer read from the command stream. If anyone
> knows how to do this, please post the answer.
We could always use a simple HLL program to call setuai() to change the
password instead. This would have an advantage in that it could
check for (and refuse to change the password for) accounts that are
marked disuser, captive/restricted, expired, or have various priviledges,
etc. It could also consult non-standard password policy files, etc.
And, it should work on newer versions of VMS (6.2+).
I could provide sample code if needed for a reasonable project, since we
already have written/implemented such code for other purposes.
This also avoids the problem of delete/erase on the command procedure
generated, as no command procedure need be executed.
Of course, this would have to be run with privs (under a priv'd account,
or installed with priv's).
Eric Jon ROSTETTER
Eric.Rostetter@utoledo.edu
Espresso est, ergo cogito... Cogito, ergo disclaimum...
================================================================================
Archive-Date: Wed, 25 Feb 1998 01:00:34 +0100
Date: Tue, 24 Feb 1998 19:00:25 EST5EDT4,M4.1.0,M10.5.0
From: reed@forge.iron.net
Reply-To: PWDCHG@lp.se
To: PWDCHG@lp.se
Message-ID: <009C24DE.EDEBFFEA.5@forge.iron.net>
Subject: Re: Changing passwords
>> Well, there is at least one of us out here.
I'm here too.
>We could always use a simple HLL program to call setuai() to change the
>password instead. This would have an advantage in that it could
>check for (and refuse to change the password for) accounts that are
>Of course, this would have to be run with privs (under a priv'd account,
>or installed with priv's).
My thought was to have one program do it all. It would take
the username, old and new passwords. It would validate the
old password first, before changing it. Thus you could install
the program with privs, and not worry about a security problem,
that I can tell.
I've seen bits and pieces of code, to check a password, and
set it, but never tried to put it all together.
If this is a good approach, does anyone know of a good start,
to get this rolling. Like others, it's been discussed, then
set aside. I'll try and put something together, if I can
get a good idea on how to start it going.
-------------
Brian D. Reed
reed@iron.net
================================================================================
Archive-Date: Wed, 25 Feb 1998 01:52:52 +0100
From: J Harper <jharper@wsipc.wednet.edu>
Reply-To: PWDCHG@lp.se
To: PWDCHG@lp.se
Subject: Re: Changing passwords
Date: Tue, 24 Feb 1998 16:48:00 -0800
MIME-Version: 1.0
Content-Type: text/plain
>My thought was to have one program do it all. It would take
>the username, old and new passwords. It would validate the
>old password first, before changing it. Thus you could install
>the program with privs, and not worry about a security problem,
>that I can tell.
I wrote a program that is installed with sysprv (may need sysnam too,
but the account I run it from already has that). File protections are
set so that only the owner has Execute access to it - this way only the
Web user account (assuming it is owner), and System people can use it.
You pass the program a name and password, and it returns a YAY or NAY in
a symbol.
>I've seen bits and pieces of code, to check a password, and
>set it, but never tried to put it all together.
I used a program in the webserver code as my base to make this program -
I found it by searching for sys$getuai in the base_code and script_code
directories.
I can send it out if people would like - mine's a bit simpler than the
one I "borrowed" from.
The program would need to honor things like minimum password length
defined in UAF (easy) and maybe even the previously-used passwords DB
and dictionary (harder). Also a 3 tries you're out would be useful, but
is hard to implement given the statelessness of the web.
J
================================================================================
Archive-Date: Wed, 25 Feb 1998 03:12:53 +0100
Date: Tue, 24 Feb 1998 21:07:29 -0500 (EST)
From: Eric <Eric.Rostetter@utoledo.edu>
Reply-To: PWDCHG@lp.se
Subject: Re: Changing passwords
To: PWDCHG@lp.se
Message-ID: <01ITYZP4WTKI005IZT@uoft02.utoledo.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
> >My thought was to have one program do it all. It would take
> >the username, old and new passwords. It would validate the
> >old password first, before changing it. Thus you could install
> >the program with privs, and not worry about a security problem,
> >that I can tell.
> I wrote a program that is installed with sysprv (may need sysnam too,
> but the account I run it from already has that). File protections are
> set so that only the owner has Execute access to it - this way only the
> Web user account (assuming it is owner), and System people can use it.
> You pass the program a name and password, and it returns a YAY or NAY in
> a symbol.
I've got code to check the old password, and code to change the password.
Putting the two together should just about do things. If interested
I can try to round up the code and post it.
> >I've seen bits and pieces of code, to check a password, and
> >set it, but never tried to put it all together.
> I used a program in the webserver code as my base to make this program -
> I found it by searching for sys$getuai in the base_code and script_code
> directories.
> I can send it out if people would like - mine's a bit simpler than the
> one I "borrowed" from.
>
> The program would need to honor things like minimum password length
> defined in UAF (easy) and maybe even the previously-used passwords DB
> and dictionary (harder). Also a 3 tries you're out would be useful, but
> is hard to implement given the statelessness of the web.
The dictionary should be easy actually, in fact mine check the secondary (site
specific) policy as well. These are documented hooks. I'm not sure about
history (we don't care about it in our application). Length should be easy
as you note. I also check for flags (disuser, captive, etc), privs (don't
allow changes to priv'd accounts), expired accounts, etc.
The idea of limiting tries is most interesting. Limiting changes is no
problem, but limiting tries in a web environment could be interesting.
Cookies would be great, except the client can turn them off, making
them useless. So another approach would be to log locations (IP addresses)
and only allow x number of change requests from a single IP address in
a given period of time. This would be a fair amount of coding though.
Other ideas?
It would probably be realistic to restrict access via IP or other means
if this was a web application, so as to prevent attacks from the outside,
but this depends on the application you have in mind (won't work if your
goal is to allow just that!)
The main reason I've never implemented a web-based password change program
is the issue of browser caching/hiding. This is were I see the most
abuse. We usually look at this for a "public lab of students" type program,
and we can't even get them to exit the browser when their done. So, any
program would need to make sure it didn't cache passwords, didn't allow
a form to be brought back with data (from the history list), etc. We've
not overcome such problems yet. Anyone else have any ideas?
Then of course there's the open password over the network problem. Some
nice proposed solutions (like a java applet to encode the password before
sending it to the server, etc) but I've never seen any code, and I'm not
a java programer *yet* (probably will be soon).
>
> J
Oh well, as usually, probably contributed more questions than answers.
For me, the changing of the password is easy, it is the web interface
that always dooms the project.
Eric Jon ROSTETTER
Eric.Rostetter@utoledo.edu
Espresso est, ergo cogito... Cogito, ergo disclaimum...
================================================================================
Archive-Date: Wed, 25 Feb 1998 03:31:51 +0100
Date: Tue, 24 Feb 1998 21:31:40 EST5EDT4,M4.1.0,M10.5.0
From: reed@forge.iron.net
Reply-To: PWDCHG@lp.se
To: PWDCHG@lp.se
Message-ID: <009C24F4.0EB87018.5@forge.iron.net>
Subject: Re: Changing passwords
>The idea of limiting tries is most interesting. Limiting changes is no
>problem, but limiting tries in a web environment could be interesting.
>Cookies would be great, except the client can turn them off, making
>them useless. So another approach would be to log locations (IP addresses)
>and only allow x number of change requests from a single IP address in
>a given period of time. This would be a fair amount of coding though.
>Other ideas?
Isn't this just what the breakin detection/evasion does?
I know I've seen it work over telnet, I assume it just
tracks the IP address of the try. If so, then it would
handle it. I don't know what happens when you verify
the password--I know you can't log in, but will it
deny a password validation if evasion is in affect?
>Then of course there's the open password over the network problem.
I suppose you could use https to do it. It also depends on
the use--if it's for local use, local dial-ins, then there
may not be an issue of it. Also, to me it's the same issue,
when using protected pages, telnetting in, etc. Still have
the open password issue. I guess if we accept using it in
the other cases, this is no different. I do like the idea
of not allowing priv'd users and those to be able to change
it--worse case is a unpriv'd account gets broken into,
which hopefully isn't a security problem, and again I see
as no more an issue than telnetting in with the password.
>It would probably be realistic to restrict access via IP or other means
I've thought that would be a good idea, to restrict it to
local calls only. That's almost all the uses anyway, to me,
but I suppose one can telnet in anyway to try and break in.
If breakin evasion doesn't work, then I'd say you do need
to restrict who can run it.
-------------
Brian D. Reed
reed@iron.net
================================================================================
Archive-Date: Wed, 25 Feb 1998 03:42:57 +0100
From: J Harper <jharper@wsipc.wednet.edu>
Reply-To: PWDCHG@lp.se
To: PWDCHG@lp.se
Subject: Re: Changing passwords
Date: Tue, 24 Feb 1998 18:42:00 -0800
MIME-Version: 1.0
Content-Type: text/plain
>I've got code to check the old password, and code to change the
password.
>Putting the two together should just about do things. If interested
>I can try to round up the code and post it.
>The dictionary should be easy actually, in fact mine check the
secondary (site
>specific) policy as well. These are documented hooks. I'm not sure
about
>history (we don't care about it in our application). Length should be
easy
>as you note. I also check for flags (disuser, captive, etc), privs
(don't
>allow changes to priv'd accounts), expired accounts, etc.
Cool.
>The idea of limiting tries is most interesting. Limiting changes is no
>problem, but limiting tries in a web environment could be interesting.
>Cookies would be great, except the client can turn them off, making
>them useless.
Exactly.
>So another approach would be to log locations (IP addresses)
>and only allow x number of change requests from a single IP address in
>a given period of time. This would be a fair amount of coding though.
This won't work if users are using Firewalls, Caching servers or dynamic
IP addresses. All users look like they are from the same IP address -
or the address can change per access!
>Other ideas?
Could limit based on username, basically only allow 3 attempts of
changes to any one user account per day or hour. An indexed file
holding the date and number of attempts indexed on the 12 character
username would do the trick. Maintenance wise, one could delete the
file at any time, causing a new blank one to be created the next time
the program is run. Worst case would be someone would be allowed 6
attempts that day!
>The main reason I've never implemented a web-based password change
program
>is the issue of browser caching/hiding. This is were I see the most
>abuse. We usually look at this for a "public lab of students" type
program,
>and we can't even get them to exit the browser when their done. So,
any
>program would need to make sure it didn't cache passwords, didn't allow
>a form to be brought back with data (from the history list), etc.
We've
>not overcome such problems yet. Anyone else have any ideas?
You can use the "expires: 0" header to force the page to expire
immidiately. Also there is a <pragma> tag that lets you specify
"nocache". The expires header is interesting in that you can't even use
the browser back button or print the page! (at least in Netscape 3.0).
Try it!
>Then of course there's the open password over the network problem.
Some
>nice proposed solutions (like a java applet to encode the password
before
>sending it to the server, etc) but I've never seen any code, and I'm
not
>a java programer *yet* (probably will be soon).
I looked into the java solution but (as with most java) found only
academic discussions and samples. It would be a cool solution though.
Best bet is to get SSL running with the OSU server and encrypt the
password page that way.
>Oh well, as usually, probably contributed more questions than answers.
>For me, the changing of the password is easy, it is the web interface
>that always dooms the project.
I don't have a need to do this either, I joined the group because it
seems like an interesting topic. Seems like many users who would need
to change their password on the web are the ones likely to forget it
(thus why they need a new one), and need to call the sysadmin anyway to
change it.
So... where to go from here?
J
================================================================================
Archive-Date: Wed, 25 Feb 1998 03:54:06 +0100
Date: Wed, 25 Feb 1998 03:54:01 +0100
Message-ID: <4670-Wed25Feb1998035401+0100-levitte@lp.se>
From: Richard Levitte - VMS Whacker <levitte@lp.se>
Reply-To: PWDCHG@lp.se
To: PWDCHG@lp.se
In-Reply-To: <3500d3ec.330956640@www.omc.bt.co.uk> (thomasgd@omc.bt.co.uk)
Subject: Re: Changing passwords
MIME-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: thomasgd@omc.bt.co.uk (Greg Thomas)
Date: Tue, 24 Feb 1998 14:18:24 GMT
Is this list still active?
*giggle* Actually, this is the first time it has become active...
$ ! WebPass.COM - OpenVMS equivalent of WebPass.expect
$ ! First draft, never even run, no error checking by Greg Thomas, 24/02/1998
$ !
$ ! P1 - Username
$ ! P2 - Old Password
$ ! P3 - New Password
$ !
$ open/write F temp.com
$ write F "$ set password"
$ write F P2
$ write F P3
$ write F P3
$ close F
[...]
That will never work. SET PASSWORD takes input directly from the
terminal, not from SYS$INPUT:. And I think it also checks that terminal
really is a terminal. I've recently made the following hack, which
solves the problem, although insecurelly unless you play with SSL.
The C hack has been compiled with DEC 5.6 on VMS 7.1 for Alpha. I've no
idea how it works on VAX or with other compilers or VMS versions.
----- change_password.com ----------------------------------------
$ set noverify
$ crlf = f$fao("!/")
$ net_write = "write net_link"
$ net_write "<DNETRECMODE>"
$ CGI_SYMBOLS WWW_ FORM_
$ SET NOVERIFY
$ if www_request_method .eqs. "GET" .or. www_request_method .eqs. "HEAD"
$ then
$! send back form.
$!
$ create net_link:
Content-type: text/html
<HTML><HEAD><TITLE>Password Change</TITLE></HEAD><BODY>
<H2>Change Your Password</H2>
<FORM method="POST" action="change_password.com">
<table>
<tr><td>Username:</td><td><input type=text name="username" size=31><br></td></tr>
<tr><td>Old Password:</td><td><input type=password name="opassword" size=31><br></td></tr>
<tr><td>New Password:</td><td><input type=password name="npassword" size=31><br></td></tr>
<tr><td>New Password (repeat):</td><td><input type=password name="npassword" size=31><br></td></tr>
</table>
<input type="submit" value=" Change "> <input type="reset" value = " clear ">
</FORM>
<HR>
The HTML to generate this page as well as the default configuration
file used by ANALOG are embedded in the change_password.com script.
</BODY></HTML>
$ exit
$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
$ else
$ !
$ ! Interpret submitted fields.
$ !
$ net_write "Content-Type: text/plain"
$ net_write ""
$ if f$type(form_fld_username) .eqs. "" -
.or. f$type(form_fld_opassword) .eqs. "" -
.or. f$type(form_fld_npassword) .eqs. ""
$ then
$ net_write "BUG! Contact the system administrator"
$ exit
$ endif
$ if form_fld_username .eqs "" -
.or. form_fld_opassword .eqs. "" -
.or. form_fld_npassword .eqs. ","
$ then
$ net_write "One of the fields is empty. Please go back and fill in!"
$ exit
$ endif
$ npasswd1 = f$edit(f$element(0,",",form_fld_npassword),"TRIM")
$ npasswd2 = f$edit(f$element(0,",",form_fld_npassword),"TRIM")
$ if npasswd1 .nes. npasswd2
$ then
$ net_write "The repeated new password didn't match the new password!"
$ net_write "Please go back and fill it in correctly!"
$ exit
$ endif
$ define sys$output nl:
$ define sys$error nl:
$ set noon
$ mcr oper:[services]change_password -
'form_fld_username' 'form_fld_opassword' 'npasswd1'
$ _tmp = $status
$ set on
$ deass sys$error
$ define/nolog sys$output net_link:
$ if _tmp
$ then
$ net_write "You have successfully changed the password for ",-
form_fld_username
$ else
$ net_write "The following VMS error occured:"
$ net_write ""
$ if _tmp .eq. %X107780D4
$ then
$ net_write " %SET-F-PWDNOTVAL, old password validation error; password not changed"
$ else
$ net_write " ",f$message(_tmp)
$ endif
$ net_write ""
$ net_write "It may be an error of yours, or a bug."
$ net_write "It it is an error of yours, please go back and correct it."
$ net_write "It it is a bug, please report it to Gladius."
$ endif
$ EXIT
----- change_password.c ------------------------------------------
#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <descrip.h>
#include <starlet.h>
#include <uaidef.h>
#include <lib$routines.h>
/* Three arguments: username, old password, new password.
Old password must match the current password for the user. */
struct itemlist {
unsigned int bufsiz:16;
unsigned int itemcode:16;
void *bufaddr;
unsigned long buflen;
};
usage()
{
fprintf (stderr, "Usage: change_password username oldpasswd newpasswd\n");
}
strupcase (char *s) /* destructive */
{
while (*s != '\0')
{
*s = toupper(*s);
s++;
}
return 0;
}
main (int argc, char **argv)
{
static char username[20],opasswd[40],npasswd[40];
$DESCRIPTOR(dsc$username,username);
$DESCRIPTOR(dsc$opasswd,opasswd);
$DESCRIPTOR(dsc$npasswd,npasswd);
static __int64 inpasswd_bin;
static __int64 oldpasswd_bin;
static unsigned char encrypt;
static unsigned short salt;
struct itemlist items_in[] = {
{ 8, UAI$_PWD, &inpasswd_bin, 0 },
{ 1, UAI$_ENCRYPT, &encrypt, 0 },
{ 2, UAI$_SALT, &salt, 0 },
{ 0, 0, 0, 0 }
};
struct itemlist items_out[] = {
{ 8, UAI$_PASSWORD, &npasswd, 0 },
{ 1, UAI$_ENCRYPT, &encrypt, 0 },
{ 2, UAI$_SALT, &salt, 0 },
{ 0, 0, 0, 0 }
};
int status;
if (argc <= 3) {
usage ();
exit (0);
}
if (strlen (argv[1]) > 12) {
fprintf (stderr, "Username \"%s\" is too long (> 12 characters)\n",
argv[1]);
exit (0);
}
strcpy (username, argv[1]);
strupcase (username);
dsc$username.dsc$w_length = strlen (username);
if (strlen (argv[2]) > 31) {
fprintf (stderr, "Old password is too long (> 31 characters)\n");
exit (0);
}
strcpy (opasswd, argv[2]);
strupcase (opasswd);
dsc$opasswd.dsc$w_length = strlen (opasswd);
if (strlen (argv[3]) > 31) {
fprintf (stderr, "New password is too long (> 31 characters)\n");
exit (0);
}
strcpy (npasswd, argv[3]);
items_out[0].bufsiz = strlen (npasswd);
status = sys$getuai (0, 0, &dsc$username, &items_in, 0, 0, 0);
if (!(status & 1))
lib$signal(status);
printf ("encrypt = %d, salt = %d, hash = %Lu\n",
encrypt, salt, inpasswd_bin);
status = sys$hash_password (&dsc$opasswd, encrypt, salt, &dsc$username,
&oldpasswd_bin);
if (!(status & 1))
lib$signal(status);
printf ("encrypt = %d, salt = %d, hash = %Lu, passwd = \"%s\"\n",
encrypt, salt, oldpasswd_bin, opasswd);
if (memcmp (&oldpasswd_bin, &inpasswd_bin, 8) != 0)
{
lib$signal (0x107780d4); /* SET-F-PWDNOTVAL */
}
status = sys$setuai (0, 0, &dsc$username, &items_out, 0, 0, 0);
if (!(status & 1))
lib$signal(status);
return 1;
}
--
R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
Tel: +46-8-26 52 47; Cel: +46-708-20 09 64; No fax right now
PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
Check http://richard.levitte.org/ for my public key. bastard@bofh.se
"price, performance, quality. Choose any two you like"
================================================================================
Archive-Date: Wed, 25 Feb 1998 04:21:37 +0100
Date: Tue, 24 Feb 1998 22:20:28 EST
From: Robert Byer <byer@mail.all-net.net>
Reply-To: PWDCHG@lp.se
To: PWDCHG@lp.se
Message-ID: <009C24FA.E00DFF60.38@mail.all-net.net>
Subject: Re: Changing passwords
>
>The idea of limiting tries is most interesting. Limiting changes is no
>problem, but limiting tries in a web environment could be interesting.
>Cookies would be great, except the client can turn them off, making
>them useless. So another approach would be to log locations (IP addresses)
>and only allow x number of change requests from a single IP address in
>a given period of time. This would be a fair amount of coding though.
>Other ideas?
>
It might not be hard to use the VMS breakin detection to handle this
and would probably be best as it would get logged.
+------------------------+--------------------------------------------+
| Robert Alan Byer | A-Com Computing, Inc. |
| Vice-President | 115 W. Washington Street, Suite 1165 |
| A-Com Computing, Inc. | Indianapolis, IN 46204 |
| Phone: (317)673-4204 | http://www.all-net.net/ |
+------------------------+-----+--------------------------------------+
| byer@mail.all-net.net | I don't want to take over the world, |
| http://www.all-net.net/~byer | just my own little part of it. |
+------------------------------+--------------------------------------+
| Send an E-mail request to obtain my PGP key. |
+---------------------------------------------------------------------+
================================================================================
Archive-Date: Wed, 25 Feb 1998 10:30:42 +0100
From: thomasgd@omc.bt.co.uk (Greg Thomas)
Reply-To: PWDCHG@lp.se
To: PWDCHG@lp.se
Subject: Re: Changing passwords
Date: Wed, 25 Feb 1998 09:30:31 GMT
Message-ID: <34f7e2b2.62831346@www.omc.bt.co.uk>
References: <4670-Wed25Feb1998035401+0100-levitte@lp.se>
In-Reply-To: <4670-Wed25Feb1998035401+0100-levitte@lp.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
On Wed, 25 Feb 1998 03:54:01 +0100, you wrote:
> $ ! WebPass.COM - OpenVMS equivalent of WebPass.expect
> $ ! First draft, never even run, no error checking by Greg Thomas, =
24/02/1998
> $ !
> $ ! P1 - Username
> $ ! P2 - Old Password
> $ ! P3 - New Password
> $ !
> $ open/write F temp.com
> $ write F "$ set password"
> $ write F P2
> $ write F P3
> $ write F P3
> $ close F
> [...]
>
>That will never work. SET PASSWORD takes input directly from the
>terminal, not from SYS$INPUT:. And I think it also checks that terminal
>really is a terminal.=20
Well, I just tried it and it works exactly as written (*) on OpenVMS
Alpha 7.1 and OpenVMS VAX 5.5-2H4. For some reason I've yet to
investigate, I get a 'ACP file access failed' and 'network partner
exited' error, but my password _is_ changed.=20
(*) Well, I had to comment out the '$ delete temp.com;*' as I was
trying on my own account, so deleting the file I'd just copied over!
Greg
================================================================================
Archive-Date: Wed, 25 Feb 1998 14:54:12 +0100
From: thomasgd@omc.bt.co.uk (Greg Thomas)
Reply-To: PWDCHG@lp.se
To: PWDCHG@lp.se
Subject: Re: Changing passwords
Date: Wed, 25 Feb 1998 13:53:56 GMT
Message-ID: <34fb21e6.79011933@www.omc.bt.co.uk>
References: <4670-Wed25Feb1998035401+0100-levitte@lp.se> <34f7e2b2.62831346@www.omc.bt.co.uk>
In-Reply-To: <34f7e2b2.62831346@www.omc.bt.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
On Wed, 25 Feb 1998 09:30:31 GMT, you wrote:
...
>Well, I just tried it and it works exactly as written (*) on OpenVMS
>Alpha 7.1 and OpenVMS VAX 5.5-2H4. For some reason I've yet to
>investigate, I get a 'ACP file access failed' and 'network partner
>exited' error, but my password _is_ changed.=20
...
Well, I've tidied it up a bit, attached. As before, it works on
OpenVMS VAX 5.5-2H4 and OpenVMS Alpha 7.1.
Greg
$ ! WebPass.COM - OpenVMS equivalent of WebPass.expect
$ ! First draft, never even run, no error checking, Greg Thomas, =
24/02/1998
$ ! Second draft, it works, basic error handling, Greg Thomas, 25/02/1998
$ !
$ ! P1 - Username
$ ! P2 - Old Password
$ ! P3 - New Password
$ !
$ on warning then goto ERROR
$ on error then goto ERROR
$ !
$ SCRATCH =3D f$getjpi( "", "PID" )
$ NO_STRINGS_MATCHED =3D %X08D78053
$ SAVE_MESSAGE =3D f$environment( "MESSAGE" )
$ !
$ !
$ !
$ open/write F 'SCRATCH'_LOCAL.COM
$ write F "$ define sys$output sys$net"
$ write F "$ set verify"
$ write F "$ set password"
$ write F P2
$ write F P3
$ write F P3
$ close F
$ !
$ copy/nolog 'SCRATCH'_LOCAL.COM 0"''P1' ''P2'"::'SCRATCH'.COM
$ delete/nolog/erase 'SCRATCH'_LOCAL.COM;*
$ !
$ type 0"''P1' ''P2'"::"TASK=3D''SCRATCH'"/out=3D'SCRATCH'.LOG
$ set message/nof/noi/not/nos
$ search 'SCRATCH'.LOG "-f-", "-e-"/out=3D'SCRATCH'.SEARCH_LOG
$ SEARCH_STATUS =3D $STATUS
$ set message 'SAVE_MESSAGE'
$ !
$ if( SEARCH_STATUS .ne. NO_STRINGS_MATCHED )
$ then
$ write sys$output "An error occurred ..."
$ type 'SCRATCH'.SEARCH_LOG
$ delete/nolog 0"''P1' ''P2'"::'SCRATCH'.COM;*
$ else
$ write sys$output "Password changed successfully"
$ delete/nolog 0"''P1' ''P3'"::'SCRATCH'.COM;*
$ endif
$ !
$ ! All done!
$ !
$ goto EXIT
$ !
$ !
$ !
$ ERROR:
$ if( f$search( "''SCRATCH'*.*;*" ) .nes. "" ) then -
delete/nolog 'SCRATCH'*.*;*
$ goto EXIT
$ EXIT:
$ exit
================================================================================
Archive-Date: Wed, 25 Feb 1998 15:23:35 +0100
Date: Wed, 25 Feb 1998 09:22:59 -0500 (EST)
From: Gandalf the Grey <SYSBRC@cnsvax.albany.edu>
Reply-To: PWDCHG@lp.se
Subject: Re: Changing passwords
To: PWDCHG@lp.se
Message-ID: <01ITZPSA4EXE8X1WP5@cnsvax.albany.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
I'm here also.
Hasn't the traditional solution been to tell VMS that SYS$COMMAND has
been redirected to SYS$INPUT, usually with the additional qualifier that
the redirection should be removed at image rundown.
$ define/user sys$input sys$command
Brian
*===========================================================================*
| Brian R Cuttler | phone 518-442-3906 fax 518-442-3697 |
| VMS System Manager | email sysbrc@cnsvax.albany.edu |
| State Univ of NY at Albany | url http://www.albany.edu/~sysbrc |
*===========================================================================*
>From: IN%"PWDCHG@lp.se" 24-FEB-1998 22:51:01.25
>To: IN%"PWDCHG@lp.se"
>CC:
>Subj: RE: Changing passwords
>
>Return-path: <owner-PWDCHG@lp.se>
>Received: from nic.lp.se by cnsvax.albany.edu (PMDF V5.1-10 #18385)
> with ESMTP id <01ITZ2552V428YCP72@cnsvax.albany.edu> for
> SYSBRC@cnsvax.albany.edu; Tue, 24 Feb 1998 22:04:05 EST
>Received: from nic.lp.se (127.0.0.1) by nic.lp.se (MX V5.0) with SMTP; Wed,
> 25 Feb 1998 03:54:03 +0100
>X-URL: http://www.lp.se/~levitte/
>Date: Wed, 25 Feb 1998 03:54:01 +0100
>From: Richard Levitte - VMS Whacker <levitte@lp.se>
>Subject: Re: Changing passwords
>In-reply-to: <3500d3ec.330956640@www.omc.bt.co.uk> (thomasgd@omc.bt.co.uk)
>To: PWDCHG@lp.se
>Reply-to: PWDCHG@lp.se
>Message-id: <4670-Wed25Feb1998035401+0100-levitte@lp.se>
>MIME-version: 1.0
>Content-type: Text/Plain; Charset=ISO-8859-1
>Content-transfer-encoding: 8bit
>Precedence: bulk
>X-PGP-Key-ID: Length=1024; ID=0xB2DEE2AD;
> Fprint="A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65"
>X-PGP-Key-URL: <http://www.lp.se/~levitte/pubkey1.asc>
>X-Date-Of-Birth: Setting Orange,the 63rd day of The Aftermath in the YOLD 3130
>X-Waved: dead chicken, dms-sig 2.2 RL1 (enhanced), rl-head 1.01,
> feedmail 7-beta-11/RL-mods-2 (enhanced), vmsmail2 (enhanced)
>List-Subscribe: <mailto:PWDCHG-request@lp.se?body=subscribe>
>List-Unsubscribe: <mailto:PWDCHG-request@lp.se?body=unsubscribe>
>X-Listname: A list to discuss password changing features through OSU httpd
> <PWDCHG@lp.se>
>
> From: thomasgd@omc.bt.co.uk (Greg Thomas)
> Date: Tue, 24 Feb 1998 14:18:24 GMT
>
> Is this list still active?
>
>*giggle* Actually, this is the first time it has become active...
>
> $ ! WebPass.COM - OpenVMS equivalent of WebPass.expect
> $ ! First draft, never even run, no error checking by Greg Thomas, 24/02/1998
> $ !
> $ ! P1 - Username
> $ ! P2 - Old Password
> $ ! P3 - New Password
> $ !
> $ open/write F temp.com
> $ write F "$ set password"
> $ write F P2
> $ write F P3
> $ write F P3
> $ close F
> [...]
>
>That will never work. SET PASSWORD takes input directly from the
>terminal, not from SYS$INPUT:. And I think it also checks that terminal
>really is a terminal. I've recently made the following hack, which
>solves the problem, although insecurelly unless you play with SSL.
>
>The C hack has been compiled with DEC 5.6 on VMS 7.1 for Alpha. I've no
>idea how it works on VAX or with other compilers or VMS versions.
>
>----- change_password.com ----------------------------------------
>$ set noverify
>$ crlf = f$fao("!/")
>$ net_write = "write net_link"
>$ net_write "<DNETRECMODE>"
>$ CGI_SYMBOLS WWW_ FORM_
>$ SET NOVERIFY
>$ if www_request_method .eqs. "GET" .or. www_request_method .eqs. "HEAD"
>$ then
>$! send back form.
>$!
>$ create net_link:
>Content-type: text/html
>
><HTML><HEAD><TITLE>Password Change</TITLE></HEAD><BODY>
><H2>Change Your Password</H2>
><FORM method="POST" action="change_password.com">
><table>
><tr><td>Username:</td><td><input type=text name="username" size=31><br></td></tr>
><tr><td>Old Password:</td><td><input type=password name="opassword" size=31><br></td></tr>
><tr><td>New Password:</td><td><input type=password name="npassword" size=31><br></td></tr>
><tr><td>New Password (repeat):</td><td><input type=password name="npassword" size=31><br></td></tr>
></table>
><input type="submit" value=" Change "> <input type="reset" value = " clear ">
></FORM>
><HR>
>The HTML to generate this page as well as the default configuration
>file used by ANALOG are embedded in the change_password.com script.
></BODY></HTML>
>$ exit
>$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>$ else
>$ !
>$ ! Interpret submitted fields.
>$ !
>$ net_write "Content-Type: text/plain"
>$ net_write ""
>$ if f$type(form_fld_username) .eqs. "" -
> .or. f$type(form_fld_opassword) .eqs. "" -
> .or. f$type(form_fld_npassword) .eqs. ""
>$ then
>$ net_write "BUG! Contact the system administrator"
>$ exit
>$ endif
>$ if form_fld_username .eqs "" -
> .or. form_fld_opassword .eqs. "" -
> .or. form_fld_npassword .eqs. ","
>$ then
>$ net_write "One of the fields is empty. Please go back and fill in!"
>$ exit
>$ endif
>$ npasswd1 = f$edit(f$element(0,",",form_fld_npassword),"TRIM")
>$ npasswd2 = f$edit(f$element(0,",",form_fld_npassword),"TRIM")
>$ if npasswd1 .nes. npasswd2
>$ then
>$ net_write "The repeated new password didn't match the new password!"
>$ net_write "Please go back and fill it in correctly!"
>$ exit
>$ endif
>$ define sys$output nl:
>$ define sys$error nl:
>$ set noon
>$ mcr oper:[services]change_password -
> 'form_fld_username' 'form_fld_opassword' 'npasswd1'
>$ _tmp = $status
>$ set on
>$ deass sys$error
>$ define/nolog sys$output net_link:
>$ if _tmp
>$ then
>$ net_write "You have successfully changed the password for ",-
> form_fld_username
>$ else
>$ net_write "The following VMS error occured:"
>$ net_write ""
>$ if _tmp .eq. %X107780D4
>$ then
>$ net_write " %SET-F-PWDNOTVAL, old password validation error; password not changed"
>$ else
>$ net_write " ",f$message(_tmp)
>$ endif
>$ net_write ""
>$ net_write "It may be an error of yours, or a bug."
>$ net_write "It it is an error of yours, please go back and correct it."
>$ net_write "It it is a bug, please report it to Gladius."
>$ endif
>$ EXIT
>
>----- change_password.c ------------------------------------------
>#include <ctype.h>
>#include <stdio.h>
>#include <stdlib.h>
>#include <string.h>
>#include <descrip.h>
>#include <starlet.h>
>#include <uaidef.h>
>#include <lib$routines.h>
>
>/* Three arguments: username, old password, new password.
> Old password must match the current password for the user. */
>
>struct itemlist {
> unsigned int bufsiz:16;
> unsigned int itemcode:16;
> void *bufaddr;
> unsigned long buflen;
>};
>
>usage()
>{
> fprintf (stderr, "Usage: change_password username oldpasswd newpasswd\n");
>}
>
>strupcase (char *s) /* destructive */
>{
> while (*s != '\0')
> {
> *s = toupper(*s);
> s++;
> }
> return 0;
>}
>
>main (int argc, char **argv)
>{
> static char username[20],opasswd[40],npasswd[40];
> $DESCRIPTOR(dsc$username,username);
> $DESCRIPTOR(dsc$opasswd,opasswd);
> $DESCRIPTOR(dsc$npasswd,npasswd);
> static __int64 inpasswd_bin;
> static __int64 oldpasswd_bin;
> static unsigned char encrypt;
> static unsigned short salt;
> struct itemlist items_in[] = {
> { 8, UAI$_PWD, &inpasswd_bin, 0 },
> { 1, UAI$_ENCRYPT, &encrypt, 0 },
> { 2, UAI$_SALT, &salt, 0 },
> { 0, 0, 0, 0 }
> };
> struct itemlist items_out[] = {
> { 8, UAI$_PASSWORD, &npasswd, 0 },
> { 1, UAI$_ENCRYPT, &encrypt, 0 },
> { 2, UAI$_SALT, &salt, 0 },
> { 0, 0, 0, 0 }
> };
> int status;
>
>
> if (argc <= 3) {
> usage ();
> exit (0);
> }
>
> if (strlen (argv[1]) > 12) {
> fprintf (stderr, "Username \"%s\" is too long (> 12 characters)\n",
> argv[1]);
> exit (0);
> }
>
> strcpy (username, argv[1]);
> strupcase (username);
> dsc$username.dsc$w_length = strlen (username);
>
> if (strlen (argv[2]) > 31) {
> fprintf (stderr, "Old password is too long (> 31 characters)\n");
> exit (0);
> }
>
> strcpy (opasswd, argv[2]);
> strupcase (opasswd);
> dsc$opasswd.dsc$w_length = strlen (opasswd);
>
> if (strlen (argv[3]) > 31) {
> fprintf (stderr, "New password is too long (> 31 characters)\n");
> exit (0);
> }
>
> strcpy (npasswd, argv[3]);
> items_out[0].bufsiz = strlen (npasswd);
>
> status = sys$getuai (0, 0, &dsc$username, &items_in, 0, 0, 0);
>
> if (!(status & 1))
> lib$signal(status);
>
> printf ("encrypt = %d, salt = %d, hash = %Lu\n",
> encrypt, salt, inpasswd_bin);
>
> status = sys$hash_password (&dsc$opasswd, encrypt, salt, &dsc$username,
> &oldpasswd_bin);
>
> if (!(status & 1))
> lib$signal(status);
>
> printf ("encrypt = %d, salt = %d, hash = %Lu, passwd = \"%s\"\n",
> encrypt, salt, oldpasswd_bin, opasswd);
>
> if (memcmp (&oldpasswd_bin, &inpasswd_bin, 8) != 0)
> {
> lib$signal (0x107780d4); /* SET-F-PWDNOTVAL */
> }
>
> status = sys$setuai (0, 0, &dsc$username, &items_out, 0, 0, 0);
>
> if (!(status & 1))
> lib$signal(status);
>
> return 1;
>}
>
>--
>R Levitte, Levitte Programming; Spannv. 38, I; S-168 35 Bromma; SWEDEN
> Tel: +46-8-26 52 47; Cel: +46-708-20 09 64; No fax right now
> PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65
> Check http://richard.levitte.org/ for my public key. bastard@bofh.se
>
> "price, performance, quality. Choose any two you like"
================================================================================
Archive-Date: Wed, 25 Feb 1998 15:34:47 +0100
Date: Wed, 25 Feb 1998 07:34:26 -0700
From: "Fitch, Randy" <Randy.Fitch@Coors.com>
Reply-To: PWDCHG@lp.se
Subject: RE: Changing passwords
To: "'PWDCHG@lp.se'" <PWDCHG@lp.se>
Message-ID: <c=US%a=MCI%p=COORS%l=EARNESTT-980225143426Z-81412@earnestt.golden.coors.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Is this list still active?
*giggle* Actually, this is the first time it has become active...
Okay, so how do I get off this list?
Randy Fitch
email: randy.fitch@coors.com
================================================================================
Archive-Date: Wed, 25 Feb 1998 15:51:23 +0100
From: thomasgd@omc.bt.co.uk (Greg Thomas)
Reply-To: PWDCHG@lp.se
To: PWDCHG@lp.se
Subject: Re: Changing passwords
Date: Wed, 25 Feb 1998 14:50:58 GMT
Message-ID: <34ff2fbc.82553155@www.omc.bt.co.uk>
References: <c=US%a=MCI%p=COORS%l=EARNESTT-980225143426Z-81412@earnestt.golden.coors.com>
In-Reply-To: <c=US%a=MCI%p=COORS%l=EARNESTT-980225143426Z-81412@earnestt.golden.coors.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
On Wed, 25 Feb 1998 07:34:26 -0700, you wrote:
...
>List-Subscribe: <mailto:PWDCHG-request@lp.se?body=3Dsubscribe>
>List-Unsubscribe: <mailto:PWDCHG-request@lp.se?body=3Dunsubscribe>
>
> Is this list still active?
>
>*giggle* Actually, this is the first time it has become active...
>
>Okay, so how do I get off this list?
>
>Randy Fitch
>email: randy.fitch@coors.com
Take a closer look at the top of your message ...
Greg
================================================================================
Archive-Date: Wed, 25 Feb 1998 16:28:00 +0100
Date: Wed, 25 Feb 1998 09:24:52 -0600
From: Glen Martin <GLENMARK@utxvms.cc.utexas.edu>
Reply-To: PWDCHG@lp.se
Subject: Re: Changing passwords
Sender: GLENMARK@utxvms.cc.utexas.edu
To: PWDCHG@lp.se
Message-ID: <34F3E364.673D2455@utxvms.cc.utexas.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <01ITYZP4WTKI005IZT@uoft02.utoledo.edu>
Eric wrote:
> The main reason I've never implemented a web-based password change program
> is the issue of browser caching/hiding. This is were I see the most
> abuse. We usually look at this for a "public lab of students" type program,
> and we can't even get them to exit the browser when their done. So, any
> program would need to make sure it didn't cache passwords, didn't allow
> a form to be brought back with data (from the history list), etc. We've
> not overcome such problems yet. Anyone else have any ideas?
>
> Then of course there's the open password over the network problem. Some
> nice proposed solutions (like a java applet to encode the password before
> sending it to the server, etc) but I've never seen any code, and I'm not
> a java programer *yet* (probably will be soon).
A Java applet which encrypts the password for handoff to a CGI script
would also solve the aforementioned browser caching problem. Form data
entered into a Java applet would not be cached. Sadly, I'm not a Java
programmer either, although I have whipped together a few simple Java
applets with CrossBasic. However, CrossBasic-built Java applets do not
currently support socket connections (even the minimal socket support
allowed by the Java applet sandbox).
Any Java programmers out there who know of some good encryption
algorithms?
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/ Glen Mark Martin E-Mail: glenmark@utxvms.cc.utexas.edu _/
_/ University of Texas at Austin Phone: (512) 475-9311 _/
_/ ACITS OpenVMS/NT Services _/
_/ Austin, TX 78712 _/
_/ World-Wide Web: http://wwwvms.utexas.edu/~GLENMARK/index.html _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
================================================================================
Archive-Date: Wed, 25 Feb 1998 16:48:24 +0100
Date: Wed, 25 Feb 1998 10:43:16 -0500 (EST)
From: INGLIS@ehsct7.envmed.rochester.edu
Reply-To: PWDCHG@lp.se
Subject: Re: Changing passwords
To: PWDCHG@lp.se
Message-ID: <01ITZS0Y8TPE0090FH@ehsct7.envmed.rochester.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Date sent: 25-FEB-1998 10:25:08
>> The main reason I've never implemented a web-based password change program
>> is the issue of browser caching/hiding. This is were I see the most
>> abuse. We usually look at this for a "public lab of students" type program,
>> and we can't even get them to exit the browser when their done. So, any
>> program would need to make sure it didn't cache passwords, didn't allow
>> a form to be brought back with data (from the history list), etc. We've
>> not overcome such problems yet. Anyone else have any ideas?
I think the standard way to make sure a page that has ANYTHING
on it you don't want reloaded, history.back() 'd or ever seen
again, is to exprire it NOW.
Of course this can't be guarenteed to work on all browsers,
but if its a classroom or Library, at least you know what
the audience browser is.
This is what I have in my notes, I use one of these...
<head> <meta http-equiv = "Pragma" content="no-cache"> </head>
In <HEAD></HEAD> as above^
OR in HTTP HEAD as below:
NAME="Expires" VALUE="Sun, 06 Nov 1994 08:49:37 GMT"
<!-- Sets the document to expire now. Should clear out the
cached version and force a reload -->
NAME="Pragma" VALUE="no-cache"
<!-- On HTTP version 1.0 servers, stops the browser and/or
proxy from caching the document. Does not work on 1.1 servers -->
NAME="cache-control" VALUE="no-cache, no-store,must-revalidate"
<!-- On HTTP version 1.1 servers, stops the browser and/or
proxy from caching the document. Also forces form elements to be
re-examined. -->
I am currently using Expires in the HEAD
seems to work most palce I;ve tried.
-g
=====================================================================
|Geoffrey B. Inglis |Phone: (716) 275-3791 |
|Univ. of Rochester Medical Ctr |FAX: (716) 256-2591 |
|Dept of Environmental Medicine |
|Box EHSC, Room G-6824 |inglis@envmed.rochester.edu |
|575 Elmwood Ave. | |
|Rochester, N.Y. 14642 |http://www.envmed.rochester.edu/ |
=====================================================================
================================================================================
Archive-Date: Wed, 25 Feb 1998 17:07:55 +0100
Date: Wed, 25 Feb 1998 11:02:58 -0500 (EST)
From: INGLIS@ehsct7.envmed.rochester.edu
Reply-To: PWDCHG@lp.se
Subject: Re: Changing passwords
To: PWDCHG@lp.se
Message-ID: <01ITZT413KVM0090FH@ehsct7.envmed.rochester.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Date sent: 25-FEB-1998 10:56:38
Hmm, you got my curiosity up.
I decided to see how my Brokerage Firm keeps
my money safe:
Looking at my Fidelity login page, I see, Two attempts:
<head>
<meta http-equiv="Expires" content="Tues 01 Jan 1970 00:00:00 GMT">
<meta http-equiv="pragma" content="no-cache">
<title>Fidelity Investments Login</title>
BTW: neither of these hide my (MicroSoft winnings ;) )
page from the back button.
I like the expire head better, that works for everything
I've tried.
-g
>I think the standard way to make sure a page that has ANYTHING
>on it you don't want reloaded, history.back() 'd or ever seen
>again, is to exprire it NOW.
>
>Of course this can't be guarenteed to work on all browsers,
>but if its a classroom or Library, at least you know what
>the audience browser is.
>
>This is what I have in my notes, I use one of these...
>
><head> <meta http-equiv = "Pragma" content="no-cache"> </head>
>In <HEAD></HEAD> as above^
>
> OR in HTTP HEAD as below:
>
> NAME="Expires" VALUE="Sun, 06 Nov 1994 08:49:37 GMT"
> <!-- Sets the document to expire now. Should clear out the
> cached version and force a reload -->
>
> NAME="Pragma" VALUE="no-cache"
> <!-- On HTTP version 1.0 servers, stops the browser and/or
> proxy from caching the document. Does not work on 1.1 servers -->
>
> NAME="cache-control" VALUE="no-cache, no-store,must-revalidate"
> <!-- On HTTP version 1.1 servers, stops the browser and/or
> proxy from caching the document. Also forces form elements to be
> re-examined. -->
>
>I am currently using Expires in the HEAD
>seems to work most palce I;ve tried.
>
>-g
>
> =====================================================================
> |Geoffrey B. Inglis |Phone: (716) 275-3791 |
> |Univ. of Rochester Medical Ctr |FAX: (716) 256-2591 |
> |Dept of Environmental Medicine |
> |Box EHSC, Room G-6824 |inglis@envmed.rochester.edu |
> |575 Elmwood Ave. | |
> |Rochester, N.Y. 14642 |http://www.envmed.rochester.edu/ |
> =====================================================================
=====================================================================
|Geoffrey B. Inglis |Phone: (716) 275-3791 |
|Univ. of Rochester Medical Ctr |FAX: (716) 256-2591 |
|Dept of Environmental Medicine |
|Box EHSC, Room G-6824 |inglis@envmed.rochester.edu |
|575 Elmwood Ave. | |
|Rochester, N.Y. 14642 |http://www.envmed.rochester.edu/ |
=====================================================================
================================================================================
Archive-Date: Wed, 25 Feb 1998 17:28:09 +0100
Date: Wed, 25 Feb 1998 11:20:53 -0500 (EST)
From: Eric <Eric.Rostetter@utoledo.edu>
Reply-To: PWDCHG@lp.se
Subject: Re: Changing passwords
To: PWDCHG@lp.se
Message-ID: <01ITZTP0GJLU007LTD@uoft02.utoledo.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
> >So another approach would be to log locations (IP addresses)
> >and only allow x number of change requests from a single IP address in
> >a given period of time. This would be a fair amount of coding though.
> This won't work if users are using Firewalls, Caching servers or dynamic
> IP addresses. All users look like they are from the same IP address -
> or the address can change per access!
I think this would be a very small percentage of the problem, and thus
would still be worth doing. This is to stop a single site from trying
to guess passwords for multiple accounts in series.
> >Other ideas?
> Could limit based on username, basically only allow 3 attempts of
> changes to any one user account per day or hour. An indexed file
> holding the date and number of attempts indexed on the 12 character
> username would do the trick. Maintenance wise, one could delete the
> file at any time, causing a new blank one to be created the next time
> the program is run. Worst case would be someone would be allowed 6
> attempts that day!
That solves the problem of someone trying to guess the password to one
account, but doesn't solve the problem of them trying to guess the password
in series to a large number of accounts.
> You can use the "expires: 0" header to force the page to expire
> immidiately. Also there is a <pragma> tag that lets you specify
> "nocache". The expires header is interesting in that you can't even use
> the browser back button or print the page! (at least in Netscape 3.0).
> Try it!
Last time I tried this, I could still recall the page from the history
list and/or back button. Maybe things have changed since then... It
was a couple years ago.
> I don't have a need to do this either, I joined the group because it
> seems like an interesting topic. Seems like many users who would need
> to change their password on the web are the ones likely to forget it
> (thus why they need a new one), and need to call the sysadmin anyway to
> change it.
We pre-create accounts for all our students, with random passwords. To use
the account, they just set the password and they're off. We currently do
this via a menu running under a captive account. There is much desire by
others to move this to the web. Hence my interest. We also of course
have people who forget their password, and use the menu to change it, which
could fill the same niche.
We don't use old password to change the password, rather some personal info
(student ID number, birthday, PIN number). That scheme is from the CIO. He
is running under the notion that those three pieces of info together are as
secure (to assure it is the owner) as a password.
> So... where to go from here?
>
> J
Eric Jon ROSTETTER
Eric.Rostetter@utoledo.edu
Espresso est, ergo cogito... Cogito, ergo disclaimum...
================================================================================
Archive-Date: Wed, 25 Feb 1998 19:27:58 +0100
Date: Wed, 25 Feb 1998 10:28:57 -0800
Message-ID: <98022510285776@rdperf.com>
From: rick@rdperf.com
Reply-To: PWDCHG@lp.se
To: PWDCHG@lp.se
Subject: Re: Changing passwords
>>
>>That will never work. SET PASSWORD takes input directly from the
>>terminal, not from SYS$INPUT:. And I think it also checks that terminal
>>really is a terminal.=20
>
>Well, I just tried it and it works exactly as written (*) on OpenVMS
>Alpha 7.1 and OpenVMS VAX 5.5-2H4. For some reason I've yet to
>investigate, I get a 'ACP file access failed' and 'network partner
>exited' error, but my password _is_ changed.=20
Both of you are right. When your password has not expired, you can use
a non-physical (say remote) terminal to do the change. When your password
has expired, it can only be changed with on a local terminal (including
decwindows).
Rick Cadruvi
R&D Performance Group, Inc.
rick@rdperf.com
================================================================================
Archive-Date: Wed, 25 Feb 1998 19:38:00 +0100
Date: Wed, 25 Feb 1998 13:36:58 EST
From: Robert Byer <byer@mail.all-net.net>
Reply-To: PWDCHG@lp.se
To: PWDCHG@lp.se
Message-ID: <009C257A.E890BDA0.20@mail.all-net.net>
Subject: Re: Changing passwords
>
>A Java applet which encrypts the password for handoff to a CGI script
>would also solve the aforementioned browser caching problem. Form data
>entered into a Java applet would not be cached. Sadly, I'm not a Java
>programmer either, although I have whipped together a few simple Java
>applets with CrossBasic. However, CrossBasic-built Java applets do not
>currently support socket connections (even the minimal socket support
>allowed by the Java applet sandbox).
>
>Any Java programmers out there who know of some good encryption
>algorithms?
>
I believe that their is a SSL perl library out their that will allow you
to so basic SSL connections using Perl.
Check out the SSLeay home page at "http://www.psy.uq.oz.au/~ftp/Crypto/"
for the link.
+------------------------+--------------------------------------------+
| Robert Alan Byer | A-Com Computing, Inc. |
| Vice-President | 115 W. Washington Street, Suite 1165 |
| A-Com Computing, Inc. | Indianapolis, IN 46204 |
| Phone: (317)673-4204 | http://www.all-net.net/ |
+------------------------+-----+--------------------------------------+
| byer@mail.all-net.net | I don't want to take over the world, |
| http://www.all-net.net/~byer | just my own little part of it. |
+------------------------------+--------------------------------------+
| Send an E-mail request to obtain my PGP key. |
+---------------------------------------------------------------------+