Richard

if you control both the client and the server it is quite simple.

Lets say you have a URL like


http:// serverip/getinfo.pgm?userid=aaaaa&password=bbbbb&account=123456


you change the url to


http:// serverip/getinfo.pgm?userid=aaaaa&hash=
4625fd63b0e96fc0d656ae7381605e48d4a0f63a319fc743adf22688613883c7&account=123456

Everybody can do a HASH - but the HASH is 'salted'

The user id aaaaa has a 'salt'-value only the client and the server knows
so the input
to the HASH algoritm is

aaaaa123456salt

There is no way you can break this security other than 'trail and error'
since you cant
deciber HASH values and the 'salt' is only known by the client and the
server.

On Tue, Aug 18, 2015 at 7:11 PM, Richard Schoen <
Richard.Schoen@xxxxxxxxxxxxxxx> wrote:

Who is this directed at ? :-)

Do tell....

Regards,

Richard Schoen | Director of Document Management Technologies, HelpSystems
T: + 1 952-486-6802
RJS Software Systems | A Division of HelpSystems
richard.schoen@xxxxxxxxxxxxxxx
www.rjssoftware.com
Visit me on: Twitter | LinkedIn

------------------------------

message: 2
date: Tue, 18 Aug 2015 17:41:34 +0200
from: Henrik R?tzou <hr@xxxxxxxxxxxx>
subject: Re: [WEB400] put in safety my Rest Web Services

A simple question ...

Do you control the programming on the client side I may be able to give
you a nearly bullit proff solution.

On Tue, Aug 18, 2015 at 5:14 PM, Richard Schoen <
Richard.Schoen@xxxxxxxxxxxxxxx> wrote:

Possibly something like this in concept:

Call to your API to authenticate user and create session info in table
(sessionid, actualuser, sessioncreatedtime, sessionexpirestime,
sourceip perhaps, whatever else you want to store for sesson ?)
http://1.1.1.1/webapi?action=login&uid=user&pwd=pass

Extract returned session ID from HTTP return data stream. Login call
can also be used to remove previous sessions for this user before
generating session.

I like using GUID as session IDs or some other long random string

Call to your actual API with session ID
http://1.1.1.1/webapi?action=getcust&cust=100&sid=sessionid

If a bad session ID, no data returned.

The XMLSERVICE CGI interface works similarly except I think you have
to pass user/pass with each call.

I've used this concept before and it seems to work fine.

Feel free to point out holes :-)

Have fun.

Regards,

Richard Schoen | Director of Document Management Technologies,
HelpSystems
T: + 1 952-486-6802
RJS Software Systems | A Division of HelpSystems
richard.schoen@xxxxxxxxxxxxxxx www.rjssoftware.com Visit me on:
Twitter | LinkedIn

----------------------------------------------------------------------

message: 1
date: Mon, 17 Aug 2015 19:42:23 +0200
from: "p.Caroti" <p.caroti@xxxxxxxx>
subject: [WEB400] put in safety my Rest Web Services

Hi



I have written and published some web Services to send and receive
data from App (Android and iOs) ; at this moment anybody that know
System I ip address and web service name could send and receive data
from my System i.
My question is how could protect the Web Service's call . I was
thinking to a dynamic password linked to date and time passed as
parameter in uri ..
Which technique do you use in this situations ?



Thanks in advance


--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing list To post a message email: WEB400@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.



--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.