How to get a Secure Web Page?

[Anchorman]

I have no idea where to start on this. We have a need to allow our users to
enter Credit Card #'s on a web page, so we need a secure page (have the
little lock at the bottom of the browser) in order to do this.

1) What is this called? (I've heard the term SSL (Secure Socket Layer)
tossed around, I don't know if this is the same or something different).

2) If I need a certificate of some sort for our server, how do I get it?

Thanks for any help you can offer.

Jesse
www.davinci-mims.com

[Jeff Cochran]

On Fri, 19 Dec 2003 13:49:31 -0500, "Anchorman"
<Je*********@da vinci-mims.com> wrote:

I have no idea where to start on this. We have a need to allow our users to
enter Credit Card #'s on a web page, so we need a secure page (have the
little lock at the bottom of the browser) in order to do this.

1) What is this called? (I've heard the term SSL (Secure Socket Layer)
tossed around, I don't know if this is the same or something different).

2) If I need a certificate of some sort for our server, how do I get it?

For those two questions, see:

http://www.iisfaq.com/default.aspx?View=P20&P=145

But if you're asking these questions, think twice about doing this.
When you screw it up and credit card numbers leak out, you'll lose
your customer base pretty darned quick. Use a payment processing
service instead.

Jeff

[Peter Foti]

"Anchorman" <Je*********@da vinci-mims.com> wrote in message
news:uH******** ******@TK2MSFTN GP12.phx.gbl...

I have no idea where to start on this. We have a need to allow our users to enter Credit Card #'s on a web page, so we need a secure page (have the
little lock at the bottom of the browser) in order to do this.
Presumably, these credit card numbers are being stored in a database? You
should take steps to make sure your database is secure as well (that is, a
user couldn't point his/her browser at a URL for the database and download
it). In addition, you should look into encrypting the credit card info
before storing it in the database. Check out ASPEncrypt
(www.aspencrypt.com) for encrypting/decrypting credit card data. They have
some good examples under the Tasks, including encrypting credit card info.

1) What is this called? (I've heard the term SSL (Secure Socket Layer)
tossed around, I don't know if this is the same or something different).
SSL is correct. You can tell when you're using SSL by the protocol in the
URL as well... it will be "https://" vs. "http://" (note the 's').
2) If I need a certificate of some sort for our server, how do I get it?

You need to purchase a certificate, or often times your host will have one
that you can use. However, using the hosts certificate will typically mean
that the URL to the secure pages will be something like this:

https://secure.myhost.com/mydomain/mysecurepage.htm

vs. having your own certificate where your URL would probably look more like
this:

https://www.mydomain.com/mysecurepage.htm

Some customers may be turned off if they have to leave your domain. You can
purchase your own certificate from Thawte (www.thawte.com) or Verisign
(though Verisign is a bit of a rip off, in my opinion). Once you have the
certificate, your host will need to install it on the server. You should
contact the host in advance though to let them know you're going to be doing
this. You can find more documentation on the the Thawte and Verisign
websites.

Regards,
Peter Foti

[Aaron Bertrand - MVP]

> When you screw it up and credit card numbers leak out, you'll lose

your customer base pretty darned quick.

Or worse. (Think lawsuit, fines, prison, etc.)

--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/

[Aaron Bertrand - MVP]

> it). In addition, you should look into encrypting the credit card info

before storing it in the database. Check out ASPEncrypt
(www.aspencrypt.com) for encrypting/decrypting credit card data.

Well, if you need to keep the data, you will also need to decrypt it. And
if you can decrypt it, so can someone else. I love the use of quotes around
the word "secret" to describe where to store the encryption key in the
registry...

--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/

[Peter Foti]

"Aaron Bertrand - MVP" <aa***@TRASHasp faq.com> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..

it). In addition, you should look into encrypting the credit card info
before storing it in the database. Check out ASPEncrypt
(www.aspencrypt.com) for encrypting/decrypting credit card data.
Well, if you need to keep the data, you will also need to decrypt it. And
if you can decrypt it, so can someone else.

Sure... if they have the decryption key.
I love the use of quotes around
the word "secret" to describe where to store the encryption key in the
registry...

LOL! Yes, that method is somewhat foolish, and not realistic in a world
where sites are hosted and you have no control over the server.
A better approach might be to store the decryption key on a PC that is not
publicly accessible, or perhaps require the user to input the decryption key
(over a secure connection, of course).

Peter Foti

[Aaron Bertrand - MVP]

> > Well, if you need to keep the data, you will also need to decrypt it.
And

if you can decrypt it, so can someone else.

Sure... if they have the decryption key.

My two thoughts were intended to be connected. E.g. you need the decryption
key to decrypt, so let's "hide" it in the registry. In addition, unless you
manually decrypt the data row by row, you must have programmatic access to
the decryption key in order to automate order processing, etc. So a
malicious user doesn't necessarily need to find/know/guess the key to
decrypt the data.

--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/

[Peter Foti]

"Aaron Bertrand - MVP" <aa***@TRASHasp faq.com> wrote in message
news:Oz******** ********@TK2MSF TNGP09.phx.gbl. ..

Well, if you need to keep the data, you will also need to decrypt it. And if you can decrypt it, so can someone else.
Sure... if they have the decryption key.

My two thoughts were intended to be connected. E.g. you need the

decryption key to decrypt, so let's "hide" it in the registry.
Hehehe... I didn't make that connection the first time... it's even funnier
when you put it like that. :)
In addition, unless you
manually decrypt the data row by row, you must have programmatic access to
the decryption key in order to automate order processing, etc. So a
malicious user doesn't necessarily need to find/know/guess the key to
decrypt the data.

True. But perhaps the decryption key could reside on a different server
(for example, behind a firewall on a LAN), where the order processing would
get the key and the send it to the database server? Would that make it any
more secure?

Pete

[Aaron Bertrand - MVP]

> True. But perhaps the decryption key could reside on a different server

(for example, behind a firewall on a LAN), where the order processing would get the key and the send it to the database server? Would that make it any more secure?

Not really. If someone from outside the firewall/LAN could initiate code
that sends the key to the database server, theoretically, they could
intercept it or initiate it to send it somewhere else. Basically, if you
put the key anywhere in plain view, someone will be able to get to it. It's
just a matter of how much work it will take, and whether the payoff is worth
it (knowledge, time, risk).

--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/

[Peter Foti]

"Aaron Bertrand - MVP" <aa***@TRASHasp faq.com> wrote in message
news:e1******** ******@TK2MSFTN GP09.phx.gbl...

True. But perhaps the decryption key could reside on a different server
(for example, behind a firewall on a LAN), where the order processing would

get the key and the send it to the database server? Would that make it

any

more secure?

Not really. If someone from outside the firewall/LAN could initiate code
that sends the key to the database server, theoretically, they could
intercept it or initiate it to send it somewhere else.

I assume you mean, for example, an order is placed, thus triggering the
order processing to begin by sending the decryption key. Presumably,
though, it would be sent via HTTPS, so as to keep it secure during
transmission.
Basically, if you
put the key anywhere in plain view, someone will be able to get to it. It's just a matter of how much work it will take, and whether the payoff is worth it (knowledge, time, risk).

True, but I don't think that behind a firewall is exactly in plain view....
except, of course, to anyone else who was behind that firewall (which in
this scenario should only be the order processing folks).

Pete