Fourth International Conference on Computer Science and Information Technology (CoSIT 2017) | Transport Layer Security | Port (Computer Networking)

Please download to get full document.

View again

of 17
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report
Category:

Documents

Published:

Views: 0 | Pages: 17

Extension: PDF | Download: 0

Share
Related documents
Description
When we need to make informed financial decisions, we seek out tools to assist us with managing and aggregating our finances. Traditionally, money management software packages have been available for personal computers; however, they were expensive and often had steep learning curve. With a paradigm shift to cloud-computing users are looking toward the web for an easier and low-cost solution. As a result, third-party companies have been formed to fill this gap. However, users have to share their login credentials with the third-party, and if that information gets compromised, an attacker can access and perform transactions on their account. We present a novel, holistic model with a new handshake protocol and access control, which authenticates and forms a sandbox around a third-party access. When utilizing these novel techniques, users’ original login credentials can remain private, and no one would be able to perform transactions on the users’ account.
Transcript
    Dhinaharan Nagamalai et al. (Eds) : CoSIT, SIGL, AIAPP, CYBI, CRIS, SEC, DMA - 2017 pp. 87– 103, 2017. © CS & IT-CSCP 2017 DOI : 10.5121/csit.2017.70410 S ECURING   O NLINE    A  CCOUNTS    VIA    N EW    H  ANDSHAKE   P ROTOCOL    AND   G RANULAR     A  CCESS   C ONTROL Mehrdad Nourai and Haim Levkowitz Computer Science Department, University of Massachusetts Lowell, Lowell, MA, USA  A  BSTRACT    When we need to make informed financial decisions, we seek out tools to assist us with managing and aggregating our finances. Traditionally, money management software packages have been available for personal computers; however, they were expensive and often had steep learning curve. With a paradigm shift to cloud-computing users are looking toward the web for an easier and low-cost solution. As a result, third-party companies have been formed to fill this gap. However, users have to share their login credentials with the third-party, and if that information gets compromised, an attacker can access and perform transactions on their account. We present a novel, holistic model with a new handshake protocol and access control, which authenticates and forms a sandbox around a third-party access. When utilizing these novel techniques, users’ srcinal login credentials can remain private, and no one would be able to  perform transactions on the users’ account.  K   EYWORDS   Security, Network Protocols, SSL Cryptography, PKI 1.   I NTRODUCTION Today, all of our financial accounts are accessible online, and often they tend to be with different institutions. When one needs to figure out the overall picture of their finances (e.g., net worth or track what is happening with their money), one would need to start by logging into each of their accounts individually. This involves remembering login credentials for each account. Ideally, for good security practices, each account should have unique login credentials, however as a convenience, users’ may use one set of credentials for most (if not all) of their accounts. Once the users log into their account, to get a big picture, they would need to download their account information in the proper format and import it to a locally installed financial software package (e.g., Intuit Quicken). Although using these tools are an improvement over tracking your financial life by hand, this process can be tedious, time-consuming, and may become overwhelming for some users that are not familiar with the world of finances. There are usability issues and inconveniences with the locally installed budgeting applications. For instance, the software localized to one computer and needs to be installed, maintained and patched to avoid security vulnerabilities. Also, they tend to be expensive, and their interfaces are a bit complicated to use and often change over time with each iteration or edition of the software. This model has a steep  88 Computer Science & Information Technology (CS & IT) learning curve and although it may have been sufficient or the only form of financial aggregation software available years ago, it is no longer the case. Thus, it is not surprising that users are migrating to online tools for managing their personal finances. The idea behind the third-party company is to provide a set of budgeting features that were previously offered by the locally installed financial software, with the added advantage of the third-party software doing all the work for free or for a small fee. For third-party companies to provide these services, they would need to login to users’ online accounts to read and collect information. The third-party can utilize desired algorithms on the users' account information to critically examine transactions, net worth, and other finances, then create and present an aggregate report in a textual or graphical manner. This is a preferred method among users, who may have used locally installed software that they had to purchase, keep updated, and perform backups on a regular basis. Although the online budget aggregate tool is an excellent and affordable tool, users have security concerns and are vulnerable to attack when they sign-up to use these types of services. The vulnerability starts by giving private accounts’ login credentials to third-party companies. If an attacker manages to compromise third-party provider’s computer, they have got users’ entire financial lives in their hands. This is because, the current design of online accounts is in a way that when someone logs into a bank account, everything that the owner of the account can do there, they can do, too. That is, it is not just that they could look at one’s bank accounts, or credit card information, they can also transact on it, too. The main idea of this paper is to showcase a novel and holistic login design with techniques for securing online accounts, by leveraging a whole new separate set of login credentials with lower permission. We explain precisely the proposed techniques which are needed to protect online accounts from potential fraudulent activity when users utilize services offered by third-party companies. The main contributions of this paper are: ã   To introduce a new handshake protocol to be used by a third-party to authenticate access to users’ online accounts (discussed in Section 4.2). ã   To introduce a new granular access control layer for fine-grained access capability to users’ online accounts (discussed in Section 7.4). 2.   E XISTING   P RACTICES   AND   I NFRASTRUCTURE   S HORTCOMINGS We now describe what is currently being used in practice and its shortcomings. 2.1. Current practices For financial institutions to provide a secure online mechanism for their customers to access their accounts, financial institutions utilize HTTPS (HTTP over SSL) technology that can be used via a web browser to access their account. The current process is as follows; one opens a web browser on the user’s computer, types in “https://” followed by the website address of their financial institution. This communication between the client and server is secured using encryption and handshaking via SSL protocol. When the page is displayed, it may contain an area within the page to obtain the customer’s login credentials or may have a sign-in link to open a login page. The mechanism used for inputting the account credentials utilizes HTML FORM INPUT tag via POST method. Customers get a couple of textboxes, one for the username and one for the password and a sign-in button. Once the user inputs the necessary fields and clicks the sign-in button, the process of user authentication gets started.  Computer Science & Information Technology (CS & IT) 89 The financial institutions’ server converts customers’ passwords into a custom hash using the algorithms they first used to create the hash (i.e., when the user first set up the account’s password), and checks for a match. If it matches, the customer is allowed to access the account. If it does not match, the server may allow a few more tries before locking the account. In addition to this process, financial intuitions often ask for more verification if their customer is signing in from a new device. This extra step involves one or more security questions that the user provided answers to when they first set up their account’s credentials. The extra step is an added security measure to ensure that even with the hacked password, the attacker would have one more challenge before gaining access to the account. With the current practices, there are variations to these steps. Hence, not all financial institutions follow a standard mechanism for authenticating their users’ access. For instance, some may display a predefined image for identification of the legitimate versus fake website that was made to look like their financial intuition’s website. Others may ask for the username on the home page but not password at first, until the user clicks the sign-in, continue, or next button. There is also the second authentication using a code that is delivered either via email, phone, or a mobile app. In general terms, the extra steps may consist of some other information that the owner of the account knows other than their password which financial institutions can ensure it is indeed the owner of the account that is attempting to accessing the account. Therefore, a hacker has to break down at least two barriers to gain access to the account. While this process works well in practice, developers designed it for the humans' capabilities, and not for machines. Thus, financial institutions had to make their interface easy enough for human use, as well as appealing to the masses that use online services. That is, the login credentials used in current practices are a compromise between security and user’s convenience. 2.2. Current Infrastructure Shortcomings The infrastructure of online accounts lacks the mechanisms to support a different form of account authentication with restrictive access. As a result, users are giving their personal access credentials to third-party companies to utilize the financial services they provide. With ever-increasing cyber-security threats, coupled with the existing industry practices, users may make themselves vulnerable to cyber criminals. The current practices have created a challenging and engaging problem that needs to be solved to keep the users safe from potential cyber-attacks. The following is a list of potential problems with the current infrastructure: ã   Users are making themselves vulnerable by giving their banking credentials in the form of username/password plus security questions and answers to third-party companies. ã   The users’ credentials are designed to be private and not shared with others. ã   Once users’ credentials are given to a third-party company, they can be stored on their server, which may be exposed to an attacker. ã   Users may use the same username/password for other accounts or other places, and as a result, if an attacker steals their credentials, they can access more than just that account. ã   Current bank accounts are full-access accounts, and as a result, once a third-party company has access to these accounts, they can perform transactions on that account. ã   Financial institutions are not the only company that always allow full-access once users’ credentials are entered. Hence, other online accounts that users share with others may be at risk of being vulnerable to an attacker.  90 Computer Science & Information Technology (CS & IT) 3.   N ETWORKING   I NFRASTRUCTURE In this section, we will discuss the foundation of the networking infrastructure that our new protocol will utilize to deliver the needed security. 3.1. Secure Channel Secure channels between two parties are needed when the transmitted information is sensitive and private while traveling over an insecure medium (e.g., the Internet). The current practices referred to as SSL, which is for securing a channel for private communications will be discussed next. 3.2. Secure Sockets Layer The current secure connection technology used on the Internet for securing communications between a client and a server is called SSL (Secure Sockets Layer), and its predecessor TLS (Transport Layer Security). Although TLS is the next generation of SSL, the term SSL is prevalent and therefore we will use it throughout this document. SSL protocol was srcinally developed by Netscape Communications in 1994 to address security issues of communicating via the Internet [1]. The protocol was a revolutionary technology for securing the Internet traffic that carried personal or sensitive information. The SSL technology is over two decades old and has evolved over time to be more secure. When new SSL vulnerabilities are discovered, computers become faster, and security demand of institutions grows, SSL will continue to evolve over time to address the needs of users. The workings of SSL depend on trust models provided by Certificate Authorities (CA) and public key infrastructure which is based on cryptography. Its underlying mechanisms protects the transmitted information integrity and security by providing authentication of the server to the client, and optionally provides authentication of the client to the server. Although SSL has several security features built-in, it is not immune to cyber-attacks (discussed in Section 8.2). Our new protocol will leverage SSL technology and its ability to secure the communications between client and server without any changes to this layer. 3.3. Transport Layer The Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) are located in this layer. TCP is a connection-oriented protocol and has three-way handshakes to establish the connection between the client (Initiator) and server (Receiver). TCP is the most reliable and prevalent protocol on the Internet because it guarantees packet delivery, ordering, and congestion control. UDP is a connection-less protocol that does not guarantee packet delivery and ordering which is typically used for streaming applications. The TCP along with IP layer, make up the TCP/IP protocol, which we will use as our transport layer protocol. No major changes are needed in this layer, however, with a minor exception that TCP flags might be set to flush out the packets. 3.4. Secure versus Insecure Network Ports The TCP and UDP transport layer protocols have 65535 ports each. The Internet Assigned Numbers Authority (IANA) assigns the ports to be used for specific protocols and general use [2]. Although some ports are used for secure protocol, there is no such thing as “secure” or “insecure” port numbers. The traffic that flows through network ports can be encrypted or in plain text. Hence it is up to the underlying protocol to use them as “secure” or “insecure” ports.
Recommended
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks