WEB Security
description
Transcript of WEB Security
![Page 1: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/1.jpg)
1
Ola FlygtVäxjö University, Sweden
http://w3.msi.vxu.se/users/ofl/[email protected]+46 470 70 86 49
WEB Security
![Page 2: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/2.jpg)
2
Outline
Web Security ConsiderationsSecure Socket Layer (SSL) and
Transport Layer Security (TLS)Secure Electronic Transaction
(SET)
![Page 3: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/3.jpg)
3
Web Security Considerations
The WEB is very visible.Complex software hide many
security flaws.Web servers are easy to configure
and manage.Users are not aware of the risks.
![Page 4: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/4.jpg)
4
Threats on the Web
![Page 5: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/5.jpg)
5
Security facilities in the TCP/IP protocol stack
![Page 6: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/6.jpg)
6
SSL and TLS
SSL was originated by NetscapeTLS working group was formed
within IETFFirst version of TLS can be viewed
as an SSLv3.1
![Page 7: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/7.jpg)
7
SSL Architecture
![Page 8: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/8.jpg)
8
SSL Record Protocol Operation
![Page 9: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/9.jpg)
9
SSL Record Format
![Page 10: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/10.jpg)
10
SSL Record Protocol Payload
≥
≥
![Page 11: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/11.jpg)
11
Handshake Protocol
The most complex part of SSL.Allows the server and client to
authenticate each other.Negotiate encryption, MAC
algorithm and cryptographic keys.Used before any application data
are transmitted.
![Page 12: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/12.jpg)
12
SSL Handshake Protocol Message Types
![Page 13: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/13.jpg)
13
Handshake Protocol Action
![Page 14: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/14.jpg)
14
Transport Layer Security
The same record format as the SSL record format.
Defined in RFC 2246. Similar to SSLv3. Differences in the protocols:
version number message authentication code pseudorandom function alert codes cipher suites client certificate types Certificate verify and finished message cryptographic computations padding
![Page 15: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/15.jpg)
15
Secure Electronic Transactions
An open encryption and security specification.
Protect credit card transaction on the Internet.
Companies involved:MasterCard, Visa, IBM, Microsoft, Netscape,
RSA, Terisa and VerisignNot a payment system.Set of security protocols and formats.
![Page 16: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/16.jpg)
16
SET Services
Provides a secure communication channel in a transaction.
Provides trust by the use of X.509v3 digital certificates.
Ensures privacy.
![Page 17: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/17.jpg)
17
SET Overview
Key Features of SET:Confidentiality of informationIntegrity of dataCardholder account authenticationMerchant authentication
![Page 18: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/18.jpg)
18
SET Participants
![Page 19: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/19.jpg)
19
Sequence of events for transactions
1. The customer opens an account.2. The customer receives a certificate.3. Merchants have their own certificates.4. The customer places an order.5. The merchant is verified.6. The order and payment are sent.7. The merchant request payment authorization.8. The merchant confirm the order.9. The merchant provides the goods or service.10. The merchant requests payments.
![Page 20: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/20.jpg)
20
Dual Signature
![Page 21: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/21.jpg)
21
Payment processing
Cardholder sends Purchase Request
![Page 22: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/22.jpg)
22
Payment processing
Merchant Verifies Customer Purchase Request
![Page 23: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/23.jpg)
23
Payment processing
Payment Authorization:Authorization RequestAuthorization Response
Payment Capture:Capture RequestCapture Response
![Page 24: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/24.jpg)
24
SET today
Didn’t really took on and is now rarely used
Main problemsComplex architecture with many
different actorsRequires clients to have certificates
![Page 25: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/25.jpg)
25
3-D Secure Protocol
3-D Secure is an authentication technology that uses Secure Sockets Layer (SSL/TLS) encryption and a Merchant Server Plug-in to: pass information and query participants to
authenticate the cardholder during an online purchase
protect payment card information as it is transmitted via the Internet. 3-D Secure is based on the three-domain model
![Page 26: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/26.jpg)
26
The Three Domain Model
![Page 27: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/27.jpg)
27
The Three Domain Model
Issuer Domain The Issuer is responsible for: managing the enrollment of their cardholders in the service
(including verifying the identity of each cardholder who enrolls) and authenticating cardholders during online purchases.
Acquirer Domain The Acquirer is responsible for: defining the procedures to ensure that merchants participating
in Internet transactions are operating under a merchant agreement with the Acquirer
providing the transaction processing for authenticated transactions.
Interoperability Domain This domain facilitates the transaction exchange between the other two domains with a common protocol and shared services.
![Page 28: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/28.jpg)
28
Implementations
3-D Secure Protocol have been implemented by several Credit Card Companies and gives similar servicesVerified by VisaMasterCard SecureCode
![Page 29: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/29.jpg)
29
Enrollment
![Page 30: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/30.jpg)
30
Purchase Transaction
![Page 31: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/31.jpg)
31
Purchase Transaction, cont.
Step 1 Shopper browses at merchant site, adds items to shopping cart, then finalizes purchase. Merchant now has all necessary data, including PAN and user device information.
Step 2 Merchant Server Plug-in (MPI) sends PAN (and user device information, if applicable) to Directory Server.
Step 3 Directory Server queries appropriate Access Control Server (ACS) to determine whether authentication (or proof of authentication attempt) is available for the PAN and device type. If no appropriate ACS is available, the Directory Server creates a response for the MPI and processing continues with Step 5.
Step 4 ACS responds to Directory Server.
![Page 32: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/32.jpg)
32
Purchase Transaction, cont.
Step 5 Directory Server forwards ACS response (or its own) to MPI. If neither authentication nor proof of authentication attempt is available, 3-D Secure processing ends, and the merchant, acquirer, or payment processor may submit a traditional authorization request, if appropriate.
Step 6 MPI sends Payer Authentication Request to ACS via shoppers device. The Payer Authentication Request message may be PAReq (for cardholders using PCs) or CPRQ (for cardholders using mobile Internet devices - see 3-D Secure: Protocol Specification - Extension for Mobile Internet Devices).
Step 7 ACS receives Payer Authentication Request. Step 8 ACS authenticates shopper using processes applicable to PAN
(password, chip, PIN, etc.). Alternatively, ACS may produce a proof of authentication attempt. ACS then formats Payer Authentication Response message with appropriate values and signs it. The Payer Authentication Response message is PARes if PAReq was received, or CPRS if CPRQ was received. (CPRS is created using values from the PARes.)
![Page 33: WEB Security](https://reader036.fdocuments.in/reader036/viewer/2022070415/56814ec5550346895dbc65bb/html5/thumbnails/33.jpg)
33
Purchase Transaction, cont.
Step 9 ACS returns Payer Authentication Response to MPI via shoppers device. ACS sends selected data to Authentication History Server.
Step 10 MPI receives Payer Authentication Response. Step 11 MPI validates Payer Authentication Response signature
(either by performing the validation itself or by passing the message to a separate Validation Server).
Step 12 Merchant proceeds with authorization exchange with its acquirer. Following Step 12, acquirer processes authorization with issuer via an authorization system such as VisaNet, then returns the results to merchant.