Bookmarks

Yahoo Gmail Google Facebook Delicious Twitter Reddit Stumpleupon Myspace Digg

Search queries

nisc wwwxxx, wwwxxx0cm, should producers of software-based services, such as atms, be held liable for economic injuries suffered when their systems fail?, wwwxxx0cm, www.webdp.net, Event 9 IIS log failed to write entry, wwwxxx jeffs, Catastrophic failure Unexpected method call sequence. 0x8000ffff (-2147418113)., ksh lock a file, [unixODBC][Driver Manager]Driver's SQLAllocHandle on SQL_HANDLE_DBC failed

Links

XODOX
Impressum

#1: secure transaction question

Posted on 2006-03-18 14:55:31 by jimbo

A software developer is contracted by state government to code a
"shopping cart" web page.

A web page file with a "*.do" extension is developed by the contractor
for the credit card checkout process. The link used to access the page
starts with "http://", not "https://" as would normally be expected.

The web page's properties say it is unencrypted and not secure. No
pop-up windows reporting a mix of secure and non-secure items occur
anywhere in the shopping cart process.

When asked about this, the contractor changes the collection process to
a web page with obvious security.

But, the contractor insists that all customer credit card transactions
in the six months of operation prior to the change were secure. The
contractor purports that encryption security was still being provided
by web page coding that was not obvious to the customer during that
timeframe.

Should the state government believe the contractor?

Report this message

#2: RE: secure transaction question

Posted on 2006-03-18 22:56:28 by keith

Just a little background. A *.do is a Java Struts extension on the J2EE
platform which is really not windows-based, however all of the stuff you're
talking about is platform-independent. No matter what, the rules are the
same when you're talking TLS (SSL) HTTPS.

In short, if you saw no HTTPS indicator, there was no security whatsoever.

This is because any scripting they would have put client-side to "protect"
data would have been accessible to anyone intercepting or accessing the page
or associated files. In this script could only be encoding/encryting code
that would have to use a non-hashed approach to retain the full information
being encrypted. Because of this, the key used to generate the encryption
would have to be shared between the web server and client in the javascript.
Even a one-time per user key would be visible in the script and could be
intercepted.

Bottom line, it sounds like the vendor is making a bad situation worse.
Hopefully this isn't a real scenario, it's just something you're
hypothesising because their statement that they had controls in place at the
time is absolutely impossible.

"jimbo" wrote:

> A software developer is contracted by state government to code a
> "shopping cart" web page.
>
> A web page file with a "*.do" extension is developed by the contractor
> for the credit card checkout process. The link used to access the page
> starts with "http://", not "https://" as would normally be expected.
>
> The web page's properties say it is unencrypted and not secure. No
> pop-up windows reporting a mix of secure and non-secure items occur
> anywhere in the shopping cart process.
>
> When asked about this, the contractor changes the collection process to
> a web page with obvious security.
>
> But, the contractor insists that all customer credit card transactions
> in the six months of operation prior to the change were secure. The
> contractor purports that encryption security was still being provided
> by web page coding that was not obvious to the customer during that
> timeframe.
>
> Should the state government believe the contractor?
>
>

Report this message

#3: Re: secure transaction question

Posted on 2006-03-19 05:05:51 by J2Be

"jimbo" <jimbo9@hippiehollow.com> wrote in message
news:1142690131.037904.218050@g10g2000cwb.googlegroups.com.. .
>A software developer is contracted by state government to code a
> "shopping cart" web page.
>
> A web page file with a "*.do" extension is developed by the contractor
> for the credit card checkout process. The link used to access the page
> starts with "http://", not "https://" as would normally be expected.
>
> The web page's properties say it is unencrypted and not secure. No
> pop-up windows reporting a mix of secure and non-secure items occur
> anywhere in the shopping cart process.
>
> When asked about this, the contractor changes the collection process to
> a web page with obvious security.
>
> But, the contractor insists that all customer credit card transactions
> in the six months of operation prior to the change were secure. The
> contractor purports that encryption security was still being provided
> by web page coding that was not obvious to the customer during that
> timeframe.
>
> Should the state government believe the contractor?
>

The transactions are not secure if there's no "https" connection (or other
connections
with different protocols that are not reported in your email) the *web page
coding* security
can be related only to the server side and rarely can be created a real
secure transaction
with the *web page coding* that will require applications client side (ex.
java applets)
that will create an encryption layer for the communication with the server.
Anyway, while the credit cards were accepted through normal "http" they were
unsecure transactions
and the contractor cannot guarantee the security for the communications
between client and server
but only for the server side data management.

Regards.


--
Leonardo Armando Iarrusso - J2Be
www: http://www.J2be.com - e-mail: info[at]J2Be.com

Report this message

#4: Re: secure transaction question

Posted on 2006-03-19 14:28:13 by jimbo

Kieth and J2be,

Thanks guys. I was thinking as much, but I wanted to confirm that the
claim of encryption security from a http web page was totally bogus.

I think they are trying to cover it up, because this would be either be
a lack of due diligence in procuring contractors, or a lack of due
diligence by the firm owner with his own people or subcontractors. The
contractor could loose his contract over this incident. They are most
likely gambling that no credit card fraud will turn up and be traced
back to that six month window that the shopping cart checkout page ran
in unsecure mode.

The page is running in https mode now, and that's what I wanted to
accomplish. Sometimes it's better to focus on creating what's right,
than to try fighting what's wrong.

Thanks for your help!

....Jimbo:)

Report this message