Institutionen för systemteknik
Department of Electrical Engineering
Examensarbete
Secure Micropayment Transactions
in a Social Media Context
Examensarbete utfört i informationsteori vid Tekniska högskolan i Linköping
av
Kajsa Goffrich
LiTH-ISY-EX-- 07/4112--SE Linköping 2007
Department of Electrical Engineering Linköpings tekniska högskola
Linköpings universitet Linköpings universitet
Secure Micropayment Transactions
in a Social Media Context
Examensarbete utfört i informationsteori
vid Tekniska högskolan i Linköping
av
Kajsa Goffrich
LiTH-ISY-EX-- 07/4112--SE
Handledare: Viiveke Fåk
isy, Linköpings universitet
Martin Källström
Primelabs AB Examinator: Viiveke Fåk
isy, Linköpings universitet Linköping, 4 October, 2007
Avdelning, Institution
Division, Department
Division of Automatic Control Department of Electrical Engineering Linköpings universitet
SE-581 83 Linköping, Sweden
Datum Date 2007-10-04 Språk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport
URL för elektronisk version
http://www.control.isy.liu.se http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-ZZZZ ISBN — ISRN LiTH-ISY-EX-- 07/4112--SE
Serietitel och serienummer
Title of series, numbering
ISSN
—
Titel
Title
Säkra mikrobetalningar för tillämpningar inom social media Secure Micropayment Transactions
in a Social Media Context
Författare
Author
Kajsa Goffrich
Sammanfattning
Abstract
The social media area is growing in general, and especially in the context of user interaction and blogs. The Internet presence of traditional businesses and companies is increasing in the same pace. As a result of this, there is a greater demand for making small payments over Internet in a secure and convenient manner. Such a payment system is required to serve as a user to user service as well as an enterprise to user service.
This thesis is providing an overview of the Internet micropayment transac-tion systems existing on the market today, as well as a discussion of the possibilities of developing a system from scratch. Further, an analysis from an information security point of view is given. In the light of the market overview, the advantages of developing a system from scratch and the security analysis a general design proposal is developed.
The outcome is a combination of a deposit and withdrawal service, found among the systems available on the market, and a transaction system developed from scratch. Important security issues are identified and ways of avoiding certain forms of attacks are provided.
Nyckelord
Abstract
The social media area is growing in general, and especially in the context of user interaction and blogs. The Internet presence of traditional businesses and compa-nies is increasing in the same pace. As a result of this, there is a greater demand for making small payments over Internet in a secure and convenient manner. Such a payment system is required to serve as a user to user service as well as an en-terprise to user service.
This thesis is providing an overview of the Internet micropayment transaction systems existing on the market today, as well as a discussion of the possibilities of developing a system from scratch. Further, an analysis from an information security point of view is given. In the light of the market overview, the advantages of developing a system from scratch and the security analysis a general design proposal is developed.
The outcome is a combination of a deposit and withdrawal service, found among the systems available on the market, and a transaction system developed from scratch. Important security issues are identified and ways of avoiding certain forms of attacks are provided.
Acknowledgments
First of all, I would like to thank my examiner Viiveke Fåk, for answering ques-tions and supporting me during the whole thesis work.
I would also like to thank Martin Källström, my supervisor at Primelabs, for giving me the possibility to complete this work. All other Primelabs staff deserve thanks too, for answering questions and giving me the opportunity to participate in the daily work at the company.
Two people have taken the time to proof-read the report, and I am very greatful for that extra weight of red ink you added to my thesis!
Finally I would like to thank both family and friends for standing to spend time with someone having only one thought in mind.
Contents
1 Introduction 1 1.1 Objectives . . . 1 1.2 Method . . . 1 1.3 Background . . . 2 1.4 Requirements . . . 2 1.5 Limitations . . . 2 1.6 Literature . . . 3 1.7 Concepts . . . 3 1.8 Disposition . . . 4 2 Electronic Payment 5 2.1 Digital Cash . . . 5 2.2 Transactions . . . 5 2.3 Technical Issues . . . 62.3.1 Hardware Based Solutions . . . 6
2.3.2 Currency . . . 6 2.3.3 Offline Capabilities . . . 7 2.3.4 Anonymity . . . 7 2.4 Macropayments . . . 7 2.5 Micropayments . . . 7 3 Security 9 3.1 Computer Security . . . 9 3.1.1 CIA Criteria . . . 9 3.1.2 Threats . . . 10
3.1.3 Access Control Matrix . . . 11
3.1.4 Security Models . . . 11
3.1.5 Identification and Authentication . . . 11
3.2 Cryptography . . . 12
3.2.1 Public Key Cryptography . . . 12
3.2.2 Symmetric Key Cryptography . . . 13
3.2.3 Digital Signatures . . . 14
3.3 Database Security . . . 15
3.3.1 Aggregation and Inference . . . 16 ix
x Contents 3.3.2 Countermeasures . . . 16 3.3.3 Database Scalability . . . 16 3.3.4 Privacy . . . 17 3.4 Design Principles . . . 17 3.5 Vulnerability Analysis . . . 18 3.5.1 Intrusion Detection . . . 18
3.5.2 The Human Factor . . . 18
4 Avaliable Products 19 4.1 PayPal . . . 19 4.1.1 Payment Service . . . 19 4.1.2 Security . . . 20 4.1.3 Transaction Fee . . . 20 4.1.4 Geographical Limitations . . . 20 4.2 Amazon Payments . . . 20 4.2.1 Payment Service . . . 21 4.2.2 Security . . . 21 4.2.3 Transaction Fee . . . 21 4.2.4 Geographical Limitations . . . 21 4.3 Payson . . . 21 4.3.1 Security . . . 22 4.3.2 Transaction Fee . . . 22 4.3.3 Geographical Limitations . . . 22 4.4 MyPay . . . 22 4.4.1 Security . . . 22 4.4.2 Geographical Limitations . . . 23 4.5 Discussion . . . 23 4.5.1 The Services . . . 23 4.5.2 Security . . . 23 4.5.3 Conclusion . . . 24 5 Design Considerations 25 5.1 System Security Issues . . . 25
5.1.1 Confidentiality . . . 25 5.1.2 Integrity . . . 26 5.1.3 Availability . . . 26 5.1.4 Threats . . . 27 5.1.5 Phishing . . . 27 5.1.6 Scalability . . . 28 5.1.7 Usability . . . 28 5.1.8 System Access . . . 28 5.2 Database . . . 29 5.3 Network . . . 30 5.4 User Interface . . . 30 5.5 Legal Issues . . . 30
Contents xi 6 Design Choices 31 6.1 Existing Systems . . . 31 6.2 Micropayment system . . . 31 6.3 Use Cases . . . 32 6.4 Security Aspects . . . 33 6.4.1 User Interface . . . 33 6.4.2 Back End . . . 34 7 Design Description 37 7.1 Overview . . . 37 7.2 Environment . . . 37 7.3 Presentation Layer . . . 39
7.3.1 Graphical User Interface . . . 39
7.3.2 Action Calls . . . 39
7.4 Business Logic Layer . . . 40
7.4.1 Business Logic . . . 40 7.4.2 Amazon FPS . . . 41 7.5 Data Layer . . . 41 7.5.1 O/R-mapping . . . 42 7.5.2 System Base . . . 42 8 Conclusion 43 8.1 Discussion . . . 43 8.2 Result . . . 44 9 Further Research 45 Bibliography 47
List of Figures
3.1 Public key cryptography. . . 133.2 Symmetric key cryptography. . . 14
3.3 Database security in the man-machine scale. . . 16
6.1 Third party deposit and withdrawal service. . . 32
6.2 CAPTCHA picture. . . 34
7.1 Design overview. . . 38
Chapter 1
Introduction
This thesis is aiming to give an overview of the micropayment market today and compare the existing systems to the possibility of developing a system from scratch. Further, an analysis of the security issues is performed and the thesis ends in a design suggestion of a micropayment system suited for human interaction in the social media context.
1.1
Objectives
The main objective is to present a security analysis of a micropayment system mainly suited for the blogosphere. The analysis is aiming to conclude with a design proposal based on a description of the Internet payment market today, together with a discussion around the benefits and disadvantages of a system de-veloped from scratch.
All evaluations and the design proposal is takeing the security point of view into consideration. Different security aspects is presented and related to the intended system.
1.2
Method
Initially the work consists of an overview of digital money in general, and especially a study of the micropayment concept. The first part is also aiming to identify in-formaition security issues of importance for this project.
The main part of this master thesis is a theoretical study in the micropayment area. The study includes a review of appropriate existing systems as well as a discussion of the possibilities to develop a system from scratch.
The work concludes with a design overview of a micropayment system. The theo-retical study is the base for the design and the main focus during the whole thesis
2 Introduction
is the information security.
1.3
Background
Today there are a lot of writers spending plenty of time on their blogs. A huge part of their spare time is spent blogging and a great amount of work is behind the most popular blogs. Most of the blogging time and effort, except a few pro-fessional bloggers, are spent idealisticly and with the readers’ appreciation as the only benefit. Contributions in guest books and systems for recommending inter-esting blogs to other readers are the most common methods of noticing blogs today. The content of many blogs is well worked through and of high quality and the blog world has an information value not to be underestimated. But among blog-gers there is a wish to get paid for their work as well. This crowd is not professional writers and does not request a salary or a large fee, but the possibility to give and receive small rewards for an informative post or an interesting blog.
Another way to earn money by maintaining a blog is advertisements. Twingly, the main product of the IT company Primelabs AB, provides an advertisement network. In order to get payed for displaying advertisements on their blogs a micropayment system can be used by the bloggers.
1.4
Requirements
In order to offer users a way to reward each other, and to collect salary for their advertises, a secure system for micropayments is needed. This system must allow each user to own a transaction account where deposits, transfer and withdrawals can be made. Another important feature is the possibility to view transaction history, in order to control the finances and to avoid fraud. Since both money and personal information are handled, the information security must not be overlooked in the system.
This thesis should provide a feasibility study in the area, with the security as-pects in focus. The output of the work is supposed to provide a foundation for development of a secure micropayment transaction system.
1.5
Limitations
The project described above is fairly time consuming and therefore some limita-tions are being put on the thesis. These restriclimita-tions are presented below. A more detailed background to the limitations can be found in later chapters.
Only online use is treated. The system is supposed to work in an Internet en-vironment and therefore the offline use possibility is not treated.
1.6 Literature 3
Tokens and biometrics are not taken in consideration. The simplicity of the system is important and therefore tokens and biometrics are not suitable.
The main focus is the technical functions and security matters, the user perspec-tive is not prioritized in this study.
Although money is a part of the subject, this thesis does not take economical or legal aspects into consideration. This is outside the focus.
The thesis is theoretical and an implementation is not part of the project. This work is a feasibility study aiming to serve as a base for further development. Therefore the study makes no claim to be exhaustive in any area.
1.6
Literature
Internet sources as well as regular books and papers have been studied in order to make the analysis as complete as possible. The literature referred to in this thesis is presented in the resources section, and all other information sources are considered as prior knowledge of the author.
1.7
Concepts
Blog: A blog is short for web log and describes a website with entries written in chronological order, commonly displayed with the last entry first. A blog can be a personal web diary or contain information and opinions in particular areas. Blogosphere: The term blogosphere is describing the blog world on the Inter-net. Both the blogs themselves and the writers are a part of the blogosphere. Social media: The concept social media is mostly dealing with sharing information, both content and knowledge. The phenomenon is based on both people wishing to be seen, and a presupposed agreement that everyone must share in order to have something to split up [11].
Web 2.0: Basically, web 2.0 is a further development of the traditional web plat-form. The former static content is dynamic in web 2.0, and more information is user generated. O’Reilley states that “The concept of ’Web 2.0’ began with a conference brainstorming session between O’Reilly and MediaLive International”, [3] and thereby declare the Web 2.0 born.
4 Introduction
1.8
Disposition
In order to make the reading easier, this section provides a brief description of each chapter in the thesis. Note that the second and third chapters are giving a background of electronic payments and computer security. These chapters are aiming to give the reader a summary of the concepts of importance in the micro-payment security area.
Chapter 1, Introduction, gives a short thesis introduction. States the background and limitations of the project.
Chapter 2, Electronic Payment, defines the conception of electronic payments. Chapter 3, Security, presents an information security overview. Contains basic computer security and cryptography.
Chapter 4, Available Products, gives a review of the micropayment products avail-able on the market today.
Chapter 5, Design Considerations, discusses the security requirements on a mi-cropayment transaction system.
Chapter 6, Design Choises, presents the general design decisions.
Chapter 7, Design Description, contains a sketch of a social media micropayment system design.
Chapter 8, Conclusion, presents the result of the litterature study and gives an analysis of the design proposal.
Chapter 9, Further Research, contains suggestions of further studies in the re-search area.
Chapter 2
Electronic Payment
This section is aiming to give an introduction to electronic payments, in order to discern the important parts in the micropayment area. The chapter begins with a brief explanation of the concept of digital cash, followed by a deeper description of the technical issues. The last part of the section contains a discussion around the micropayment view of digital money transactions.
2.1
Digital Cash
The concept of digital cash is also known as electronic money and, according to Wikipedia [4], electronic cash, digital money or digital currency. The different notions all refer to money transferred electronically, typically over the Internet or some other computer network.
The investor glossary [3] defines digital money as “A form of electronic money that can be used to pay for goods and services, most often on the Internet or another electronic medium”.
In this thesis the above definition of digital money is used, regardless of the transaction type. In some contexts digital cash referres to money transactions performed without a third party interference, for example a bank. This thesis, however, is not separating these concepts and all synonyms are used to describe electronic money transactions in any form.
2.2
Transactions
To carry out electronic transactions of money the basic requirement is that the user has some kind of personal computer, which is able to handle payments and other transactions. The computer must be able to send, receive and, at least in an offline context, store the cash data in a secure way.
6 Electronic Payment
In order to implement an electronic transaction system a connection point be-tween the different users is also required. This spider in the cash web is, in most cases, a bank or some other supplier of network financial services.
Further, the different users and the supplier must be connected to a network to be able to transfer money to each other. This network can be a local network, a closed network or the Internet. This thesis concentrates on transactions over the Internet.
2.3
Technical Issues
This section defines and briefly explains the technical issues that are central for this thesis. To get further information on the different topics the reader is rec-ommended to read the papers related to digital cash written by David Chaum [15].
2.3.1
Hardware Based Solutions
There are a handful of existing transaction security solutions based on hardware on the market today. This means some kind of token is being used to achieve secure money transfers. Different kinds of electronic wallets, for example USB connectable hardware and wallets located on the computer hardware, are used to achieve this security to payment systems. The increased security is an obvi-ous advantage with these solutions, but the security benefits come with a certain drawback, namely the lack of portability. With an electronic wallet stored on a certain computer it is impossible to reach an account from anywhere else than the users primary computer. If an external wallet is used, admittedly it is possible to use any other computer for payments, but to the cost of carrying the wallet around. Since one of the most important requirements on a transaction system of this kind is simplicity, the hardware based solutions are not considered. The additional se-curity an electronic wallet is offering is rejected to make way for the simplicity of software based solutions.
2.3.2
Currency
The question of which currency to use is interesting when dealing with electronic payments. As opposed to traditional cash payment situations where in most cases the local currency of the country is used for practical reasons, the currency choice of electronic payments does not matter. Since the electronic transferring of money does not handle any traditional cash, the comprehension of the value is of more importance when choosing between different currencies. It is of certain interest that the users recognize and accept the money, otherwise the payment system will probably not be used.
2.4 Macropayments 7
2.3.3
Offline Capabilities
A money transaction system aiming to serve for example stores, restaurants and cafés is likely forced to implement support for offline use in order to be accepted by the customers. A system made for Internet use on the other hand does not have that offline requirement, and since the implementation freedom is much higher without offline requirements this study is restricted to online systems.
2.3.4
Anonymity
There are some anonymity aspects on electronic payments. There are security benefits in storing all transactions since that offers rollback possibilities, but at the cost of traceability and thus no anonymity. Another difficult issue is the possibility to see who sent the money, which can eliminate the anonymity and advance traceability. Certain ways to implement secure and anonymous money transfer systems do exist [15] but since that criterion strongly limits the design this analysis does not demand anonymous transactions.
2.4
Macropayments
Electronic payments are roughly divided into macro- and micropayments. The macropayments category deals with online payments above one dollar [21]. The one dollar limit is not considered as an exact limit here but rather a target. Macro-payments are however dealing with large amounts of money and therefore the se-curity issues require some extra attention.
Macropayments are, according to Mandadi, divided into four different categories [21]. These are card based systems, electronic cash systems, electronic check sys-tems and mobile payment syssys-tems. Since this thesis is limited to online syssys-tems without tokens the electronic cash systems are the only ones of interest.
The idea of electronic cash is to store money digitally and allow immediate ex-change in transactions. The user is able to perform withdrawals, deposits and pay-ments without the involvement of a traditional bank. When transferring money by using electronic cash it is much more difficult to guarantee anonymity than with old-fashioned paper money [15], but since this thesis does not aim to investigate the possibilities to achieve anonymity in monetary transactions the problem will not be further discussed here.
2.5
Micropayments
As opposed to macropayments that are dealing with payments larger than one dollar, micropayments are usually referring to transactions with small amounts of money. The upper limit is not exactly one dollar, if anything the hallmark of micropayments is rather a tradeoff between simplicity and security. The micro-payment area is neither split up in categories nor as well structured as the macro
8 Electronic Payment
payment area. Therefore the term micropayment is simply used for referring to a fast and convenient method for electronically transferring a rather small amount of money [22].
Chapter 3
Security
When dealing with money transfer, information security is an important issue. This section will give an overview of the central matters in the information security area, and present some reflections concerning the area. The discussion below will serve as a foundation for the system design considerations.
3.1
Computer Security
Computer security is a central part of information security. When dealing with computer security the technical point of view is rather obvious, but there are other important matters to be considered too. Restricting users´ access to only the parts they need is a way to prevent intrusion, as is taking the human factor into consideration.
3.1.1
CIA Criteria
Bishop [14] divides computer security into three main categories, confidentiality, integrity and availability. These three are often referred to as the CIA criteria, and are commonly occurring in the area of computer security.
Confidentiality describes the hiding of information or resources. The need for keeping information secret varies depending of how sensitive the information is and if the context is considered dangerous. In military use and sensitive govern-ment or company situations the “need to know” principle [14] is often enforced. This principle only allows access to certain data for users who need it while the default is to restrict all users.
Integrity refers to whether data sources are trustworthy or not, and the integrity of data is often discussed when looking into preventing improper or unauthorized change of the information. The term includes both data integrity, which means the content of the information, and the origin integrity, or the data source, often referred to as authentication. The source of the information often bears on the
10 Security
trust people place in the information and due to that the integrity of the informa-tion is important [14].
As opposed to the confidentiality and integrity criteria availability does not re-fer to the data itself but to the ability to reach and use the information requested. An unavailable system is almost as bad as no system at all according to Bishop [14], and due to that the aspect of availability is important for the information reli-ability as well as the system design. Attempts to block availreli-ability are called denial of service attacks and can be difficult to avoid, because of the often circumspect character of the attacks.
3.1.2
Threats
A potential violation of security is called a threat. The fact that the violation might occur causes a threat, irrespective of the actual occurrence of the violation. These violations, or attacks, are prepared for and guarded against in order to keep the CIA security. Gollmann [18] categorizes threats by the damage they cause. By using Microsoft’s STRIDE threat model for software security he defines the categories as:
• Spoofing identities: the attacker pretends to be somebody else.
• Tampering with data: the attacker increases his/her privileges by changing
security settings.
• Repudiation: a user denies to have performed an action, for example
mount-ing an attack or makmount-ing a purchase.
• Information: when information looses its value due to information transport
to the wrong parties.
• Denial of service (DoS): can make resources temporarily unavailable. • Elevation of privilege: a user gains more privileges than he/she is supposed
to have.
After categorizing the potential attack the possible sources can be identified. Sev-eral questions are being asked during the identification procedure, such as:
• Is the attacker an insider or an outsider?
• Could an outsider be a contractor or a former member?
• Does the intruder have direct access to the system or is the attack performed
remotely?
Another way of increasing security is, according to Gollmann [18], to analyze in detail how an attack is performed. Attack trees are a method to analyze attacks by building dependency graphs, where the nodes are the different steps in an attack. These trees are often used when the intruder uses attack scripts, automated attacks, since the scripted attacks are more predictable than hand made.
3.1 Computer Security 11
3.1.3
Access Control Matrix
A system is secure under certain conditions, and this is described in a protection system. A classical formulation of a protection system is the access control matrix system, which describes allowed access in both operating systems and databases using a matrix. The matrix is a tool that can describe the current protection state in a human readable way. It gives an overview of the access in a system and offers an opportunity to early discover when a user has too much or insufficient rights [14].
3.1.4
Security Models
To formulate a security model certain rules need to be stated, for example rules for system access. The rules can be informally described in an ordinary document written in natural, human readable language. These documents are often inconsis-tent, ambiguous and suffer from omissions, and therefore formal models of writing security policies are used. Gollmann [18] states that “Security models play an important role in the design and evaluation of high assurance security systems.” and describes how the design process ought to start from a formal security model and a high-level system specification.
There are several formal security policy models available on the market today, and the Bell-LaPadula model is the most important [18]. Other important security models are Biba and Clark-Wilson, suited for integrity models, and the Chinese Wall method suited for dynamically changing access rights. The Harrison-Ruzzo-Ullman model defines authorization systems and contains policies for changing access rights and for creation and deletion of objects. A different approach to the same problem is the information flow model which analyzes the information flow in order to create security rules [18].
3.1.5
Identification and Authentication
The concepts of identification and authentication are often referred to together but have different meanings. Identification is the action of claiming an identity, the username when logging on to a computer is the identification of the user. Au-thentication is the step where the identity claim is proven, the password step in the computer logon action [18].
Bishop [14] describes three different ways of authenticating identification, namely by something the user knows, by something the user has and by something the user is. One or more of these can be used, depending on the security level, risks and outer conditions.
The typical way to authenticate by something the user knows is using passwords. The user is supposed to carefully manage the password and is often expected to choose the password following certain security criteria. But the server side of the application must also be aware of the security and protect the passwords carefully.
12 Security
In this approach the password is considered a secret and another example of au-thentication by something the user knows is PIN codes.
When the security approach of something the user has is used, the user has to present a physical token to be authenticated. A key that opens a lock, an iden-tification card, an identity tag or a smart card are examples of physical tokens serving as something the user has.
Biometric schemes are used when authentication is performed by something the user is. The characteristics of a person, such as face, fingerprints, iris patterns, hand geometry or in some cases DNA, are examples of biometric schemes [18].
3.2
Cryptography
This section will describe the two main lines in the cryptography field, symmetric key algorithms and public key algorithms. An introduction to digital certificates and hash functions will be given as well.
Cryptography originates from the two Greek words kryptós and gráfo, which means secret respectively write, and is the science of message security. The orig-inal message is called plaintext, and by using an encryption key the message can be encrypted. The result is called ciphertext, and is not readable for anyone but the owner of the key. To retrieve the original message decryption is made with the decryption key [28].
3.2.1
Public Key Cryptography
In a situation where Bob wants to send a message to Alice, but when they do not have the possibility to share a secret key, a public key algorithm is the solution. All public key cryptosystems, also called asymmetric key systems, share the ben-efit of not having to transfer a secret key between the participants in the secret conversation.
Both Alice and Bob each have a public key and a private key. The private key is supposed to be kept secret and revealed to no one, while the public key is pub-licly available. When Bob wants to send a message to Alice he uses her public key, available for all users, to encrypt the message. Thereby the plaintext will be unreadable, and can only be decrypted with Alices private key. Since Alice is the only person who has that key at her disposal, she is the only one who can read messages encrypted with his public key. An overview of the procedure is shown in figure 3.1 on page 13 [27].
The most commonly used algorithm to implement a public key cryptosystem is RSA. The algorithm was proposed in 1977 by Rivest, Shamir and Adelman, and is based on the idea that factoring large primes is hard to carry out. Using RSA,
3.2 Cryptography 13
Figure 3.1. Public key cryptography.
Alice starts by choosing two secret primes p and q and, on the basis of them, computes:
n = pq
Then Alice chooses an e with:
gcd(e, (p − 1)(q − 1)) = 1
The next step is to compute d as:
de = 1(mod(p − 1)(q − 1))
Following these calculations Alice makes e and n public and keeps p, q and d secret. To send a message m to Alice, Bob encrypts m as:
c = me(mod n)
Bob keeps m secret and sends c to Alice. Alice decrypts c to get m by computing:
m = cd(mod n)
By following these steps, the RSA algorithm, Bob can send a secret message to Alice, without previously sharing a key. Since huge primes are involved and several computations have to be made, the public key algorithms are not the fastest on the market. For faster, but still secure, communication, RSA, or a similar asymmetric key system, often is used to securely transfer a symmetric key [27].
3.2.2
Symmetric Key Cryptography
As opposed to public key systems, in symmetric key algorithms both sender and receiver share the same secret key, and use the same algorithm to encrypt and
14 Security
Figure 3.2. Symmetric key cryptography.
decrypt messages. If Alice wants to send a message m to Bob, they have to agree on a key k. The key can, for example, be transmitted by using an asymmetric algorithm. The first step in a symmetric key system is that Alice encrypts m to c by using a function Ek:
c = Ek(m)
Now, it is cryptographically secure to send the cipher text message c to Bob over a public network. When he receives the message c, Bob uses the inverse function on the message ciphertext c to obtain the original message m:
Dk(c) = Dk(Ek(m)) = Ek−1(Ek(m)) = m
A schematic outline of the procedure is shown in figure 3.2 on page 14 [28]. Two commonly used symmetric key algorithms are the Data Encryption Standard (DES) and its successor, the Advanced Encryption Standard (AES). DES is also available in an extended version called Triple Data Encryption Standard (3DES), where DES is used three times, with separate keys, on a message. The symmetric key algorithms are much faster than the public key systems, and thereby better suited when transferring long messages. A drawback compared to asymmetric ci-phers is that the shared secret key must be transmitted between the sender and the receiver in some secure way, often by using a public key system [27].
3.2.3
Digital Signatures
Using signatures is an old and widely spread manner of identification and associ-ation of identities to documents. Classically the signatures have been written by hand, or made by sealing a document. But in the context of electronic payments, an electronic signature is better suited for the purpose. This section describes two steps in making a digital signature, RSA signing and hashing.
3.3 Database Security 15
To sign a document the RSA algorithm is used backwards. That is, the secret key d is used to achieve a signature, and the public key e for verification. To sign a message m, the encrypted message y is attached to the original message. The signature y is calculated as:
y = md(mod n)
To verify that the signature is valid, the public key e is used:
z = ye(mod n)
Presupposed that z = m the signature is accepted and considered valid, otherwise the signature is invalid [27].
According to Trappe and Washington [27], in RSA signing, and most digital signa-ture schemes, the signasigna-ture is at least as long as the message. The disadvantage is obvious when the messages are getting longer. To avoid transferring unnecessary long messages due to the signatures, a hash value of the message can be signed instead. A Public hash function h is used and, starting with a message m, the hash h(m) is calculated. The output is much smaller, and signing the hash (m) is therefore a significantly faster procedure than signing the whole message. To verify the signature, the hash of the message is simply calculated using the public hash function h. This hash function is compared to the value of the signature, verified by the public function. If the calculated hash corresponds to the value of the signature, the signature is considered valid, and otherwise invalid [27].
3.3
Database Security
According to Gollmann a database “does not merely store data, it provides infor-mation to its users” [18]. Therefore the inforinfor-mation security is just as important as the protection of data when dealing with database security. Mechanisms that allow users to retrieve information in a controlled manner are an important issue as well. Operating systems manage data and databases manage information, and due to this, Gollmann [18] places database security near the human side of the man-machine scale in figure 3.3 on page 16. Database users perform operations aiming to reach the content of the entities, the most common use is search. Protecting certain sensitive information from being directly reached by a query is not a big deal, but there are other ways to gain the same information from a database than by a direct query. Besides exact data an intruder can use bound values, negative results, existence of data or probable values to gain the information looked for.
16 Security
Figure 3.3. Database security in the man-machine scale.
3.3.1
Aggregation and Inference
In the database security field the terms aggregation and inference are important. The sensitivity level of aggregate functions in a database, for example the sum and average functions or the max and min functions, are likely to be lower than the sensitivity level of each entity. The security problem here is when sensitive data can be derived from average functions by performing certain queries. This manner is referred to as the inference problem.
In a database, the inference problem is divided into four different types of at-tacks. These are commonly referred to as direct attacks, indirect attacks, tracker attacks and linear system vulnerability. To perform a direct attack the aggregate is computed over a small sample and the information is thereby leaked, while an indirect attack includes several queries over larger samples combined to reach the information. Tracker attacks is a more efficient way of performing indirect attacks and the linear system vulnerability is a more complex way of performing a tracker attack since algebraic relations between datasets are used to construct equations and thereby yield the desired information [18].
3.3.2
Countermeasures
A huge part of the database security literature deals with attacking by analysis of statistical inference and tracker attacks, but still there exists no solution to the problem. As long as the database allows statistical queries to be run there is a risk for inference. This risk can be limited by suppressing access to obviously sensitive information, disguising the data, changing the database design and tracking the users´ queries [18].
3.3.3
Database Scalability
To achieve sufficient scalability, and thereby avoid security problems due to high loads on small databases, it is a good idea to facilitate exchange of the database. By using an abstraction layer providing O/R-mapping between the system logic and the database, this can be achieved. The database abstraction also forces developers to formalize their database calls, which might avoid security holes due to mistakes hidden in complicated SQL statements.
3.4 Design Principles 17
3.3.4
Privacy
When storing personal data legal issues are important. Data such as name, ad-dress, age and credit card numbers are considered sensitive and should be pro-tected. The OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data [8] contain international recommendations and used to-gether with the local law, privacy can be protected.
3.4
Design Principles
Eight different principles for the design and implementation of security mecha-nisms were stated by Saltzer and Schroeder [23]. These principles draw on the ideas of simplicity and restriction and will be described in this section.
The principle of least privilege states that a subject should be given only those privileges that it needs in order to complete its task.
The principle of fail-safe default states that, unless a subject is given explicit access to an object, it should be denied access to that object.
The principle of economy of mechanism states that security mechanisms should be as simple as possible.
The principle of complete mediation requires that all accesses to objects be checked to ensure that they are allowed.
The principle of open design states that the security of a mechanism should not depend on the secrecy of its design or implementation.
The principle of separation of privilege states that a system should not grant permission based on a single condition, but rather provide separated access con-trols.
The principle of least common mechanism states that mechanisms used to access resources should not be shared, in order to minimize the number of information channels.
The principle of psychological acceptability states that security mechanisms should not make the resource more difficult to access than if the security mechanisms were not present.
These principles [14] are fundamental to the design and implementation of security mechanisms. Some of the principles originate from a non-technical environment, and because of that they comprise not only the technical view of an implementa-tion but also the human interacimplementa-tion aspect.
18 Security
3.5
Vulnerability Analysis
In a computer system vulnerabilities can occur not only in hardware and software but also in policies, organization and management. Therefore this section is not limited to discussing vulnerabilities in hardware and software but to the whole computer system.
3.5.1
Intrusion Detection
Intrusions can be detected and prevented in different ways. Models such as anomaly modeling, misuse modeling or specification modeling can be used to de-tect possible illicit use of a system. The archide-tecture of the system can be designed in a way that benefits security and the system can be monitored to detect attack-ing.
A penetration study can be performed in order to evaluate the strength of all security controls in the computer system. In this case, the goal is to violate the security policy and verify that the security system can handle the situation and detect an intrusion. In this case procedural and operational controls are examined as well as technical.
Flaw classification is important when evaluating security mechanisms in a sys-tem. In the ideal case a flaw should be classified as the same at all levels in a system. This is however not always possible, since a flaw can take different ex-pressions at different levels, but the flaw classes shall be consistent in all cases [14].
3.5.2
The Human Factor
Another risk when dealing with computer security is that users oppose security, either they are aware of their actions or not. People tend to avoid security mech-anisms when they affect the daily work, and causes time consuming delays. The design principle of psychological acceptance states that the security features should not be noticeable, otherwise users will try to walk around them. This is even worse than a total lack of security, since the administrators could believe their network to be protected although some users create security holes on their own [14].
Chapter 4
Avaliable Products
There are several products intended to perform electronic payments on the market today. This chapter describes a selection of available products, suited for micro-payments.
4.1
PayPal
In December 1998 the company Confinity was founded by Mark Levchin, Peter Thiel and Luke Nosek. Initially Confinity was a Palm Pilot payment and cryp-tography company, with the Palm Pilot on line payment service PayPal as their main product, but later on PayPal converted to be a pure online payment service. In March 2000 Confinity merged with the Internet financial vice company X.com, and through the fusion PayPal received its present appearance [19].
In October 2002 PayPal was purchased by eBay, and thereby replaced Billpoint as eBay´s primary payment service. During the years lots of the competitors of PayPal have been shut down or went bankrupt, and now PayPal serves almost all of the US Internet payment market, and 190 of the markets around the whole world. Transactions can be made in 17 different currencies, and PayPal operates locally in 13 countries [9].
4.1.1
Payment Service
PayPal is licensed as a money transmitter, not as a bank, and thereby adheres to the local law in the US state where the specific payment takes place. In Eu-rope eBay is located in Luxemburg, where the service is considered as a bank and thereby eBay in Europe must obey the banking laws of Luxemburg.
Apart from money transactions, deposit and withdrawal, PayPal offers its cus-tomers a request service. This service is aiming to fill a need of an electronic way of setteling a debt [9] [24].
20 Avaliable Products
4.1.2
Security
To achieve transaction security, and protect buyers and sellers, PayPal has a secu-rity center. The main task for the center is to educate customers, and increase the risk awareness. Another part of the security center work is to prevent phishing at-tacks, mainly by warning the customers and manually look for phishing attempts. PayPal in not well suited for anonymous transactions. Since the company of-fers a seller security, which guarantees the money back under certain conditions, transaction track-back is required [24].
Another PayPal security feature, which Jackson [19] claims actually is invented by PayPal, is the Gausebeck-Levchin test. The test is widely known today under the abbreviation CAPTCHA, meaning Completely Automated Public Turing test to tell Computers and Humans Apart, and frequently used today [2].
A new security feature, introduced in the beginning of 2007, is security keys. All users are offered to buy a security key to achieve an extra security layer. While logging in, the user is given a code to be entered in the security key, which returns another code. The new code is to be entered into the login form and the login will be carried out [9].
4.1.3
Transaction Fee
PayPal offers two different types of accounts, personal and premier/business ac-counts. Both types are free to open and it is free of charge sending money to them. There are however country dependant fees for recieving and withdrawing money. The country dependant fees can be found, together with other fees, at the PayPal homepage [9]. In Sweden for example, a fee of 7 SEK is added for all withdrawals below 500 SEK.
4.1.4
Geographical Limitations
There are local PayPal sites in 14 countries, and in another 21 countries, among them Sweden, PayPal offers full service. In another 15 countries send, receive and withdrawal are allowed only to US bank accounts, while users in most other countries only have the possibility to send money. A complete list of full-service countries can be found at the PayPal homepage [9].
4.2
Amazon Payments
Amazon.com was founded in 1994 by Jeff Bezos, and the company launched its services in 1995. Initially Amazon was operating as an online bookstore under the name Cadabra, but the company soon changed its name to Amazon, and extended its activity to online sales of other products. Amazon was founded in the US, but the company has established separate web pages in several other countries. Over
4.3 Payson 21
the years Amazon has become leading in online shopping, not only with respect to books but also movies and music [1] [25].
4.2.1
Payment Service
Amazon Flexible Payments Service (Amazon FPS) is a payment service designed specifically for developers, and aiming to serve third parties such as online stores. The service is containing a set of APIs, built on top of the Amazon payment struc-ture and aiming to allow money transactions between both users and computers. The result is a flexible and scalable payment system, containing not only ordinary money transaction features but also micropayment support [1] [13].
4.2.2
Security
The Amazon FPS marketing states that Amazon, after a decade of development and testing, has developed a reliable and secure payment infrastructure. The third parties using Amazon FPS are able to offer their customers the same trusted payment service available on the Amazon site today. Thanks to the proven fraud detection capabilities, chargeback controls and risk management techniques, the company can guarantee money transaction security [1] [13].
4.2.3
Transaction Fee
The system described above is not something Amazon gives away for free; all cus-tomers are charged when using Amazon FPS. The fees are depicted below. Transactions above $10: 1.5% + $0.01
Transactions below $10: 1.5% + $0.01
Transactions below $0.05: 20% with a minimum fee of $0.0025
Note that the prices are for the US market and all other markets are charged with an extra 1% per transaction. The non-US payments can be made by credit card only.
4.2.4
Geographical Limitations
Amazon FPS does not have any geographical limitations, except for the extra charge of all customers outside USA.
4.3
Payson
The Internet transaction company Payson is focusing on the Swedish market, and offers a payment service for private persons as well as for companies. A payment solution suited for both small and larger customers are provided, where, apart
22 Avaliable Products
from payments using Paysons own accounts, payment can be made by VISA card, Master Card and all Swedish Internet banks [10].
4.3.1
Security
Payson states that the company can guarantee secure money transactions, since the market leading security features are being used. Among these features 3D-secure, SSL and PCI certification are represented. To provide bookkeeping possibilities, it is possible to download the transaction history as an Excel sheet [10].
4.3.2
Transaction Fee
Payson claims to be the only company offering this all in one service for Swedish Internet payments, and the service fee is 3 SEK plus 3 % of the transaction sum.
4.3.3
Geographical Limitations
The Payson service is admittedly suited for micropayments, and the transaction fees are not noticeably higher than other services. Further, the security can be con-sidered sufficient. This is not based on the real security featuresthough, since the specifications does not reveal enough information to form an opinion, but based on the transaction guarantee where the company assures complete security and therefore compensates any harm due to insufficient security.
Despite the micropayment opportunity and sufficient security, Payson is not very well suited to serve as a transaction system in the social media context. A main goal with the transaction system is to connect people, and allow interaction re-gardless of the geographical placement. Therefore a payment system suited for the Swedish market exclusively is not a feasible choice in this thesis.
4.4
MyPay
MyPay is another Swedish payment company offering micropayment services to its customers. The company was founded in 1983, and has been offering different payment and business solutions since then. MyPay offers its services to both com-panies and private persons, and provides overall solutions for electronic payments. The service also includes multi currency payments and payment via SMS, MMS or telephone [6].
4.4.1
Security
The security of the MyPay services is guaranteed by a policy where it is the service supplier who suffers possible losses due to safety problems or hacking attacks. A privacy policy is also stated on the site, stating that all personal information will be handled with care and in accordance with Swedish law [7].
4.5 Discussion 23
4.4.2
Geographical Limitations
Like Payson, MyPay is suited for micropayments and provides sufficient security. But the service also involves the same geographical problem, since it is focused on the Swedish market. Therefore MyPay is not a possible choice here either.
4.5
Discussion
Due to the geographical limitations, PayPal and Amazon services are the possi-ble choices, when aiming to create an internationally adaptapossi-ble payment service located in Sweden. In this section these services are compared, followed by a discussion of their suitability in the social media context.
4.5.1
The Services
Both PayPal and Amazon FPS are feasible choices for a micropayment system in the social media context.
Amazon provides a more international service and a developer centered API, and is thereby very well suited for third party use. A drawback though is that the service is still in its beta edition, and therefore the trustworthiness is reduced a bit. There are few examples of other implementations using the system, and due to that Amazon is considered a bit risky.
PayPal, on the other hand, has been on the market for a long time and there are plenty of examples on working third party implementations. The PayPal sys-tem is however not created as a payment service aiming to serve other applications, and the interaction might therefore be a bit more complicated. Another problem is that PayPal does not provide an international service as good as the one Amazon is providing.
4.5.2
Security
Since money is handled, there are several potential threats against a micropayment system. Both Amazon and PayPal have been in the business for years, and have had time to develop security mechanisms and policies. Due to this, both compa-nies consider it justified to guarantee their customers a safe system, and thereby be responsible for all potential losses originating in safety shortages. Given these guarantees, the safety of the systems is deemed sufficient, even though no infor-mation regarding the computer or database security is available.
From the CIA criteria, confidentiality and integrity is guaranteed. The availabil-ity criterion is more abstract, and whether it is fulfilled or not is fairly dependant on the requirements on the system. Since Amazon claims a 24/7 service [1] and PayPal states that the uptime exceeds 98% [9], the availability is sufficient.
24 Avaliable Products
4.5.3
Conclusion
The PayPal and Amazon systems are conceivable for the end user service, such as deposit and withdrawal. Because of their long experience of customer service they could serve as a link between a transaction system and the user, but the systems would hardly be appropriate as micropayment systems. Due to their transaction fees the user would lose too much of the transaction sums, and therefore neither PayPal nor Amazon is suitable for serving as a social media micropayment system. Therefore the choise fell on developing a transaction system från scratch, using an existing service for deposit and withdrawal.
Chapter 5
Design Considerations
Another possibility to create a secure micropayment system is to develop the trans-action system from scratch. To create a system suited for micropayments, certain problems must be considered. These problems, and possible ways of handling them, are presented in this chapter.
5.1
System Security Issues
In this section a discussion of general security aspects can be found, as well as a link to the CIA creteria. Both micropayment system specific issues and software environment matters will be handled.
5.1.1
Confidentiality
In the micropayment context, confidentiality is rather important. User details must be hidden in order to achieve sufficient security. In addition to the imple-mentation specific details and built in security, there are even more matters to consider.
There is a tradeoff between login security and simplicity. High security require-ments result in long and complicated passwords, geographical limitations, login procedures in many steps and other delays irritating users. On the other hand, too loose security requirements might for example lead to users choosing bad pass-words and thereby increasing the risk of intrusions in the system.
Another tradeoff is between the user information confidentiality and the possi-bility of identity recovery. Aiming to accomplish total confidentiality of the user information, developers and administrators of the micropayment system can not have any contingency to reach the user information. In theory, by protecting the login, password, account balance and similar information the user will be protected from insider attacks as well. But this protection against insider threats is achieved at the cost of no account recovery. If the user for some reason loses the login or
26 Design Considerations
password, there is no possibility of recovery or even balance withdrawal. Neither the administrator nor the user has access to the account in that case, and therefore the money will be locked in.
5.1.2
Integrity
The integrity of the data in a micropayment system is of immense importance. A scenario of unauthorized information changes in this context might cause mon-etary loses, both for the user and the company offering the service. In order to prevent these kinds of consequences, both data integrity and authentication must be protected.
Data integrity can be granted by using different ways of marking the data. Digital signatures, watermarks and similar features might be used, and thereby ensure that the data is still in its original form.
The authentication is a somewhat more complicated issue. An electronic pay-ment system does not contain personal interaction, and with that no possibility to identify users in traditional ways, such as by ID or personally. Therefore au-thentication must rely on login details, passwords, electronic identification or in a similar manner. This creates special kinds of demands on the user identification, since it is the only way for the service provider to verify the identity of the user. Another aspect is the integrity of the provider. The user must be able to ver-ify that the interaction really is coming about with the right party. A challenge and response system might be helpful in this case, alternatively a system where the user submit some information to the provider when signing up for the service. This information is then presented by the provider during the login phase, and thereby the user can authenticate the service provider.
5.1.3
Availability
In a micropayment system the availability is certainly important, but still not as important as confidentiality and integrity. A reasonable downtime due to main-tenance aiming to increase security in the system is a fair tradeoff. Since the functionality of a micropayment system is not dependant on 24 hours uptime, any downtime is only annoying for the users and not critical for the information secu-rity.
Compared to downtime, information losses are much worse. Regardless of the reason, which might be system crashes, environmental conditions, the human fac-tor or a DoS attack, losing information in a micropayment system is devastating. There is little chance for users getting their money back in case of a system crash. This affects both trustworthiness and economy for the company which makes the service available, and therefore information losses must be prevented. Possible ways of achieving that could be backup systems, different physical locations of
5.1 System Security Issues 27
the servers and information redundancy. These preparations are important, since data losses are not acceptable unless a nuclear war is breaking out and the USSR is reforming to drop a bomb on Sweden.
5.1.4
Threats
There are a number of possible violations of the security in an electronic transac-tion system [20]. The system must be able to detect intrusion attempts and resist attacks.
Spoofing identities are one of the most common threats to a system available on the Internet. Trying to use a micropayment system pretending to be someone else is a profitable business, since the attacker can transfer money from the stolen account to his or her own. Phishing attacks are also very common here; a discus-sion of counteracting phishing attacks is following in the next section. Password cracking through brute force attacks is another way of spoofing identities. Strong passwords handled with care are an efficient way of avoiding this [17].
Another probable threat is repudiation. A user might perform a transaction or withdrawal and then claim that an action never really was carried out. One way to avoid this type of attack is logging of all transactions, and thereby achieving a possibility to verify that the transaction really took place. This is not useful in a situation where the user admits the action, but claims an intruder was making it. This threat, however, is to be considered as identity spoofing, and by avoiding that, such statements can be considered false.
5.1.5
Phishing
Phishing is a term for evesdropping of sensitive information, either by passive or active man-in-the-middle attacks or by social engineering [18]. The most efficient way to avoid phishing is to never provide any information that could be of value for an intruder. It is almost impossible to guarantee complete security, but a good strategy is to never send valuable information in plain text. By encrypting impor-tant key information, such as passwords, before transmitting them over a network, a value caught by a phishing attack will be worthless. An exception is when the attacker is performing an active man-in-the-middle-attack, but otherwise encryp-tion is providing good security.
A very common way of encrypting passwords is by using a token, like the PayPal key described in chapter 4. In this case the user has a token containing a cipher function and the encryption key, and the key is used for encryption of a value pro-vided by the service, for example an Internet bank. The ciphertext is transmitted back to the service, which has the same key and therefore is able to verify the correctness of the password. With this approach, any evesdropped value will be worthless. The Internet service provides a new value to be encrypted each time and since the evesdropped value already has been used, access is denied.
28 Design Considerations
This cipher function can be stored at the users local computer too. Except the obvious drawback of being locked to the home computer, storing the cipher func-tion and key locally provides a possibility for sophisticated attacks such as trojans finding the key, signing transactions and similar actions.
Since the requirements on the micropayment system state that neither tokens nor locally stored security mechanisms are going to be used, another way of avoid-ing phishavoid-ing attacks must be used. Naturally, a combination of both ways would be the best way from a security point of view, but with the given conditions user education is the best way of avoiding phishing attacks. The tradeoff between sim-plicity and security has fallen out in favor of simsim-plicity in the phishing case. A rather efficient way to avoid phishing attacks is by educating the users in reveal-ing them. If the users never follow links or expose their passwords there are good chances of protecting the system. But it is a bit harder to discover a trojan used for changing bookmarks, or a false DNS server. Users refusing to follow the secu-rity regulations are causing problems, as are naive users. The naive users might be a risk in the token based systems too, assuming that they actually provide a whole series of codes even though the response is not correct.
The conclusion is that it is impossible to provide total security by using only static passwords, but there are ways to minimize the threats and limit the harm. In a micropayment system the sums transferred are usually small, and the possible damage caused by a phishing attack is therefore limited.
5.1.6
Scalability
To serve as a long-term micropayment system in international use, the system must be scalable. On a small scale, an optimized database is not required but when the number of users increases the database must be able to grow.
5.1.7
Usability
The usability is actually outside the area of this thesis. It is however an important issue, and during design and implementation it is a good idea to have the usability in mind.
5.1.8
System Access
Concerning developers and administrators the system access is a sensitive issue. The benefits of giving complete system access to all developers and administrators are obvious, but there are certain drawbacks to that approach. By giving all staff complete access to a micropayment system in operation, the staff is automatically being responsible for whatever happens in the system too. Apart from the in-convenience of being responsible for possible problems outside ones working area,
5.2 Database 29
there are other risks with too wide system access. A serious threat is that the more people with access, the more possible responsible people in case of problems and thereby more opportunities for the attacker to blame somebody else. Also, there is an increased risk of someone breaking the rules when the access is widened. To avoid such unnecessary threats, and restrict system access only to people needing it, using an access control matrix (see 3.1.3) is of advantage.
Another task is to create a security model (see 3.1.4), formally stating system access and responsibility. To avoid the unnecessary work of creating a model from scratch, one of the formal security policies available on the market today can be used. A good choice is a model of the Bell-LaPadula type. The model is a broad and well dependable method, although it is a security model and therefore must be slightly modified here in order to be suitable.
5.2
Database
The different kinds of inference attacks on databases are not a huge threat here, since there is no reason for giving database access to anyone except developers and administrators. Admittedly these have total access, but the allowed access erases the need of attacking the system. Others are not supposed to have database access at all, and are thereby not a threat in the inference case.
A more serious threat is external database attacks and break in due to insuffi-cient surrounding security. It is of considerable importance to make sure that the operating system, and other surroundings, are secure. Firewalls and built in security features should be used, and the principle of fail-safe defaults ought to be applied.
It is also of importance to apply the principles of complete mediation, separation of privilege and common mechanisms. These are helpful when avoiding intrusions due to the wrong people having too much access. By using these principles people are not able to open security holes by mistake, due to accesses they did not know they had.
Another way to protect developers and administrators from opening security holes by mistake, or preventing them from using their privileges to make intrusions, is to never store plain text information. By encrypting or hashing passwords and other sensitive information before storing, there are no possibilities to gain that information even with complete database access. This does not prevent changing of information, but there are small possibilities of changing a password without being discovered.
30 Design Considerations
5.3
Network
The network security is somewhat outside the scope of this project. Nevertheless, it is a really important issue and must be considered during development, and even more while setting up the micropayment system environment. It is recommended to follow current standards [26] to achieve a secure and scalable environment.
5.4
User Interface
The user interface must, as the rest of the system, be implemented with informa-tion security in mind. When creating the user interface the developer should pay certain attention to the principles of complete mediation and separation of privi-lege. If correctly implemented these principles are very useful in order to achieve information login security for the users.
The single most important principle in the user interaction context is the principle of psychological acceptability. Even though the security features are perfect and the implementation is following all rules, the users must still accept them. Users not following, or even opposing, the security mechanisms are a great threat. The identification and authentication of users is another delicate problem. Since no smart cards or similar tokens are being used, the identification is relying only on username and password. Therefore it is a good idea to use strong passwords, and consider providing random passwords to the user without the possibility to change them. If the identification is not properly made it is not possible to au-thenticate users without risking the system security.
Another standpoint to make is whether the information should be encrypted. By choosing a development environment containing cryptography features, and by using these built-in mechanisms, a fairly secure system can be achieved without increasing the work amount too much.
5.5
Legal Issues
Since an electronic payment system is dependant on storing personal information in one form or another, the privacy is an important matter. There are both ethical and legal aspects in this question. These issues, together with economical questions, are not at all part of this project. Therefore they are left for further research.
