× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Walden,

I'm going to have to admit to a case of not seeing the forest for the trees on 
this one (still, messing with CIPHER was fun and I will need to use what I 
developed down the road) or at least trying too hard to make what I'm doing 
work more like the save password feature in IE and Mozilla based browsers. 
We're currently using a session cookie that's basically what you describe as 
option three. The session cookie is a hash of a GUID and a few other things and 
we store the hash and an expiration date in a table. Since it's a session 
cookie that expires after a period of inactivity, we're not putting anything to 
lock it to a single machine but that's a great idea.

Thanks,

Matt

-----Original Message-----
From: Walden H. Leverich [mailto:WaldenL@xxxxxxxxxxxxxxx]
Sent: Wednesday, October 06, 2004 9:29 AM
To: Web Enabling the AS400 / iSeries
Subject: [WEB400] FW: CIPHER'n problem


All,

This is moved from the RPG list since it's become a Web topic, not an
RPG topic.

Matt,

I still wouldn't store the password in the cookie, encrypted or not. If
someone breaks the encryption, or just hijacks the cookie, they'll be
able to get on w/o a problem and no one will know. Since you've moved to
forms-based authentication you have many more options since you are in
complete control of the process. We've done a couple of ways in the
past. 

First, store the username and a flag that says they're authenticated.
The advantage here is that while they can still hijack the cookie, at
least then can't get the password to allow them access from anywhere
since the password isn't in the cookie. The disadvantage is that a
change of the password on the server side doesn't invalidate the stored
login.

Second, store the username and a hash of the password, but not the
password itself. This way if the password is changed on the server side
the hash is now different and invalid.

Third, and my current favourite, store a GUID in the cookie. The GUID is
your key to a server-side table that contains a list of "remember me"
entries. If they have a valid "remember me" then they bypass the login
process. The advantage here is that you can kill all "remember me"
entries for a user by deleting the rows in the table. So if the user
doesn't have access to a PC any longer he can still force that PC to
forget. You can also add logic like allowing a user to remember me from
only one PC at a time. When they click remember me from the second PC
you delete the row for the old PC. The only thing you need to take care
of is how you deal with changed passwords. You can just delete all
remember me entries when the password changes, or store some hash of the
password in the remember me row.

JMTCW.

-Walden

------------
Walden H Leverich III
President & CEO
Tech Software
(516) 627-3800 x11
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com 

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
 
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Haas, Matt
Sent: Tuesday, 05 October, 2004 13:55
To: RPG programming on the AS400 / iSeries
Subject: RE: CIPHER'n problem

I know better than to save credit card or SSN information in a cookie
(encrypted or not). Basically, what we did is switch from basic
authentication to using forms and I've been asked for the site to
remember the login information so the customers don't need to type in
their user id and password (basically, the same functionality the
"remember me" check box in the basic auth dialog gives you). If my
thinking's correct, this will be better security than what we had with
basic auth since login information will be passed both to and from the
server encrypted instead of Base64 encoded. If you have better ideas
about accomplishing this, I'd love to hear them but we should either go
off-list or switch to either Web-400 or Ignite/400 since it really isn't
an RPG topic.

If nothing else, I know there are other things coming up that will
require encryption and now I have a working program to use as a base for
something production level.

Matt

-----Original Message-----
From: Walden H. Leverich [mailto:WaldenL@xxxxxxxxxxxxxxx]
Sent: Tuesday, October 05, 2004 12:28 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: CIPHER'n problem


>For an upcoming project, I need to store some encrypted data in 
>a cookie which has me looking at using the CIPHER MI 
>instruction to do this. 

OK, I know this isn't what you asked, but I can't resist... WHY? You
shouldn't be saving anything in a cookie that needs to be encrypted. If
you're saving any personal information (name, credit card #, SSN, etc.)
in the cookie, please don't. If you're saving the key to your
server-side files that contain that information then why bother
encrypting it? 

-Walden


------------
Walden H Leverich III
President & CEO
Tech Software
(516) 627-3800 x11
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com 

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.