× 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.


  1.  Home
  2. WEB400
  3. August 2015

Re: put in safety my Rest Web Services

Brad

My post said "If you are insisting on a user id and password being passed..."
Personally I wouldn't do that, but if somebody wants to go for the user id and password option the I think it's better in the header, regardless of whether or not it's a web service. Although the values are base64 encoded, that doesn't mean that the encoded values cannot also be encrypted (with a salt). The base64 encoding isn't for security, it is simply to ensure 100% that the header is valid.

As an aside, the "passport" technique, where users can authenticate using their Facebook, Google, Twitter (etc) account is pretty useful - especially for mobile apps. However, they are not all consistent in the standard they adopt. Oauth2 is a little complicated. It is good where you have no control over which clients are going to use your service. If, on the other hand, you are in complete control of the server and client code, I think I'm with some of the earlier posters that suggest a simple salted token technique.

Rgds
Kevin

Sent from my iPad

On 19 Aug 2015, at 02:28, Bradley Stone <bvstone@xxxxxxxxx> wrote:

Not really for web services. Basic Authentication isn't any more secure.
Base64 is easily decrypted.

Tokens are what I'm seeing used most often now (using OAuth).

Why reinvent the wheel? I bet there are services and/or tutorials out
there that would be able to set up APIs for your application to use OAuth
2.0 tokens. It's a little overhead and a slight learning curve, but worth
it.

You may be able to implement Google ID OAuth2.0 pretty easily (but this
would require a Google account for the user). This means no more user ids
and passwords for your applications. All they need is a Google Account
(this could be done with Facebook, Twitter, etc accounts as well).

I wrote an article on it here on how I implemented it into our
FieldExit.com site:
http://www.fieldexit.com/forum/display?threadid=177

It may lead you down a path. It's not meant as a "just copy this and it
will work" example. More of an exercise to see what standards are in use
out there today.

Also, i assume you're services are using SSL as well.

Without a full view of your applications and the servers and languages in
use, both client and server, it's hard to suggest things as well.

Brad
www.bvstools.com



On Tue, Aug 18, 2015 at 4:03 PM, Kevin Turner <
kevin.turner@xxxxxxxxxxxxxxxxxxxx> wrote:

If you are going to the bother of insisting on a user id and password
bring passed then wouldn't it be normal to have those credentials (encoded)
in the HTTP header (not in a query string or post data)?

Sent from my iPad

On 18 Aug 2015, at 21:41, Pete Helgren <pete@xxxxxxxxxx> wrote:

Henrik,

This is where I plan to go and don't know if this is what the OP was
concerned about. What I don't want to have happen is that the
http://serverip/getinfo.pgm?userid=aaaaa&password=bbbbb&account=123456 is
changed to
http://serverip/getinfo.pgm?userid=aaaaa&password=bbbbb&account=654321
and they are given account access to that account. Yeah, I could check to
make sure that the account is valid for that user, plus a few other steps,
but hashing and salting are a bit more straightforward and require fewer
steps (IMHO)...

Pete Helgren
www.petesworkshop.com
GIAC Secure Software Programmer-Java

On 8/18/2015 1:29 PM, Henrik Rützou wrote:
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.

--
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 email has been scanned by iomartcloud.
http://www.iomartcloud.com/


________________________________

NOTICE: The information in this electronic mail transmission is intended
by CoralTree Systems Ltd for the use of the named individuals or entity to
which it is directed and may contain information that is privileged or
otherwise confidential. If you have received this electronic mail
transmission in error, please delete it from your system without copying or
forwarding it, and notify the sender of the error by reply email or by
telephone, so that the sender's address records can be corrected.




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


CoralTree Systems Limited
Company Registration Number 5021022.
Registered Office:
12-14 Carlton Place
Southampton
Hampshire
SO15 2EA
VAT Registration Number 834 1020 74.
--
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.


___________________________________________
This email has been scanned by iomartcloud.
http://www.iomartcloud.com/


________________________________

NOTICE: The information in this electronic mail transmission is intended by CoralTree Systems Ltd for the use of the named individuals or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone, so that the sender's address records can be corrected.



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


CoralTree Systems Limited
Company Registration Number 5021022.
Registered Office:
12-14 Carlton Place
Southampton
Hampshire
SO15 2EA
VAT Registration Number 834 1020 74.

As an Amazon Associate we earn from qualifying purchases.

This thread ...
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.