Your Credentials Are Compromised, Do Not Panic: You Can Be Well Protected Issa Khalil
Zuochao Dou
Abdallah Khreishah
Qatar Computing Research Institute Hamad bin Khalifa University, Doha, Qatar
New Jersey Institute of Technology Newark, New Jersey, United States
New Jersey Institute of Technology Newark, New Jersey, United States
[email protected]
[email protected]
ABSTRACT In this paper, we leverage the characteristics of round-trip communications latency (RTL) to design and implement a novel highly secure and usable web authentication scheme, dubbed CLAS. CLAS uses, in addition to the traditional credentials, round-trip network communications latency to uniquely identify users. CLAS introduces a novel network architecture which turns RTL into a robust authentication feature that is extremely difficult to forge. CLAS offers robust defense against password compromise because, unlike many traditional authentication mechanisms, it is resilient to phishing/pharming, man-in-the-middle, and social engineering attacks. Most importantly, CLAS is transparent to users and incurs negligible overhead. Our experimental results show that CLAS can achieve 0.0017 false positive rate while maintaining false negative rate below 0.007.
Keywords Web authentication; network communications latency; Gaussian distribution; password compromise
1.
INTRODUCTION
The proliferation of web services combined with the current web authentication vulnerabilities fuel authentication based attacks as evidenced by the 2015 RSA study [5], which shows that 80% of successful cyber-attacks exploit authentication credentials. Traditional web authentication approaches (e.g., legacy password, 2-factor authentication via SMS, universal two factor authentication, biometric authentication, one time passwords, etc.) suffer from diverse limitations including: potential compromise of credentials (e.g., through internal observation, social engineering, mobile malware [8], etc.), having single point of failure (e.g., Facebook Connect), vulnerability to active man-in-the-middle attacks (e.g., through phishing/pharming [7]) and sometimes have poor user experience (e.g., typing of extra bits of information and using extra channel/device.). Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from
[email protected]. c 2016 ACM. ISBN 978-1-4503-2138-9.
DOI: 10.1145/1235
[email protected]
In this work, we design and develop a novel, highly secure, and usable authentication mechanism, dubbed Communications Latency Authentication Scheme (CLAS).CLAS complements traditional web authentication mechanisms by overcoming many of their limitations. A key question in motivating this work was if it is possible for an authenticator to distinguish whether an ongoing login attempt was initiated by the legitimate user or by a perpetrator in possession of the legitimate credentials. Profiling the behavior of the user was one of the first solutions that jump straight ahead as it proves to be effective in flagging some of the most dangerous attacks. However, many of the state-of-the-art profiling techniques use features (e.g., geo-locations, IP and port entropy, bandwidth utilization, packet loss rate, percentage of unencrypted traffic flow, etc.) that are not robust, that is, attackers could easily change the features that capture their behavior to match those of the victim and, hence successfully impersonate her. On the contrary, CLAS uses an authentication feature that is designed to be extremely difficult to forge. CLAS uses round trip network communications latency to uniquely identify users. Network communications latency is defined as the time elapsed between sending out a packet and receiving back its acknowledgment. It has been observed that the statistics of network communications latency between two communicating parties approximately follow Gaussian distribution regardless of the Internet access technologies used (e.g., WiFi, wireline, 3G/4G, etc.) [10]. Changing the login location changes the mean and the standard deviation of the Gaussian distribution, that is, the statistics of network communications latency can be used to authenticate users. However, the use of RTLs for authentication introduces two main challenges, the potential manipulation of RTL values and network instabilities [10]. CLAS addresses the first challenge by inserting a special one-way forwarding device, dubbed Stealthy Relay (SR), in the round trip route between the clients and the server as detailed in Section 3.3. This novel design secures RTL measurements and hence, makes it extremely hard to manipulate. The latter challenge is addressed through data pre-processing, long-term dynamic temporal profiling, and multi-profiling techniques, as detailed in Section 6.2. CLAS considerably enhances the security posture of user authentication, especially for non-mobile users. Nevertheless, traditional authentication mechanisms and CLAS are complementary and can be combined to offer more robust and flexible defenses against password compromise, as detailed
is subject to multi-factor authentication vulnerabilities including the compromise of the out-of-band-channel through, for example, man-in-the-middle or theft and loss of devices. Universal two factor authentication (UTF) [14] utilizes public key cryptography to enable highly secure authentication, however, it has serious usability issues and suffers from the same public key cryptography issues including key revocation and trusted third party requirement. It has also been shown that UTF is susceptible to man-in-the-middle-scriptin-the-browser attack [9]. Figure 1: CLAS authentication flowchart. in Section 5. Additionally, man-in-the-middle attacks cannot succeed against CLAS because such attacks change profile parameters and hence result in login failure. Moreover, CLAS has very light real-time overhead and is transparent to end users beacause they are not required to provide any additional authentication information beyond the username and password. Our contributions in this work are summarized as follows: • Propose a novel highly secure and usable web authentication scheme based on round-trip network communications latency. • Design and implement a novel network architecture, which makes CLAS resilient to manipulation attacks. • Build a prototype of CLAS and conduct extensive experiments to practically evaluate its security guarantees and performance overhead. • Augment the basic authentication approach of CLAS with solutions that enable secure authentication in mobile scenarios. The rest of this paper is organized as follows. Section 2 presents the related work. Section 3 presents the design and the implementation details of CLAS. Section 4 presents the experimental setup and results. In Section 5, we present extensions to CLAS to support mobile user authentication. In Section 6, we discuss network instabilities and same location login limitations. In Section 7, we conclude this study.
2.
RELATED WORK
In [10], the authors perform extensive experiments to measure network communications latency and conclude that it approximately follows a Gaussian distribution with mean and standard deviation that can be used to characterize different cloud servers. We partially leverage this observation to develop our authentication scheme. In [15], the authors propose a packet delay-based scheme to detect man-in-the-middle (MitM) attacks. They assume that delay increases in the existence of MitM attacker. However, this scheme suffers from serious security issues because packet delay as presented can be easily manipulated. Since 2010, Gmail launched a service that enables its users to detect suspicious account login activities based on IP information [1]. However, IP-based verification is too weak due to the easiness by which IP-based information can be manipulated (through proxy servers, VPN, IP hijacking etc.). Early 2015, Yahoo launched a new service called “on-demand” passwords [4], which allows people to login to their Yahoo accounts using a short password the company texts to their phones, instead of having to remember their own passwords. This service is a form of 2-factor authentication and hence,
3.
COMMUNICATIONS LATENCY-BASED AUTHENTICATION SCHEME (CLAS)
In this section, we first present the attack model, and then present the design and the implementation details of CLAS, which include: the authentication protocol, the architecture for building secure profiles, profiling sample size and the decision algorithm.
3.1
Assumptions and attack model
We assume that the registration phase when the reference profiles are established is secure. We also assume that the Stealthy Relay (to be introduced later) is secure and is connected to a network segment that cannot be accessed by attackers. CLAS defends against attackers whose goal is to impersonate legitimate users and does address denial of service attacks in which attackers attempt to prevent login of legitimate users. In addition, CLAS, solely by itself, does not defend against perpetrators who both compromise legitimate user credentials and have accesses to her profiled location. Such attacks can be thwarted by integrating CLAS with other authentication mechanisms, such as browser fingerprinting, as explained in Section 5.
3.2
CLAS authentication protocol
As depicted in Figure 1, CLAS ecosystem comprises three entities, namely, User, Server and Stealthy Relay (SR). CLAS authentication consists of registration phase and authentication phase. Registration starts when a user creates a new account with the intended server (step 1 in Fig 1). The registration daemon at the server starts the profiling process through which multiple packets are exchanged with the user to establish its reference RTL profile. The server asks for the user’s permission to engage in the profiling process (step 2 in Fig 1). After the user accepts the request (step 3 in Fig 1), the server sends a sequence of packets, called Profiling Signals, to the SR and the SR forwards them to the user (step 4 in Fig 1). The user acknowledges the reception of each profiling signal by sending direct acknowledgments back to the server (step 5 in Fig 1). A profiling signal is a very small packet (similar to ping request and reply messages) intended to measure the RTL between the server and the user. Detailed analysis of the number of profiling signals required to establish sufficiently accurate profiles is provided in Section 3.4. The RTL for each profiling signal (steps 4 and 5 in Fig 1) is computed at the server as the time elapsed between sending out the signal and receiving its acknowledgment back. The average delay of all the profiling signals and the standard deviation of the delay comprise the profile of the user. We note here that profiles are measured and stored at the server. The users do not learn and, hence, do not need to remember any thing about their reference profiles. This novel design gives CLAS its user transparency feature.
Figure 2: CLAS architecture. In the authentication phase, downstream (step 8 and 9 in Fig 1) profiling signals from the server are acknowledged by the user. Using the profiling signals and acknowledgments, the server computes the mean and the standard deviation of the communications latency in real time (Step 11 in Fig 1). The server, then, compares the real-time measured profile parameters with those of the reference profile. Based on the result of the comparison, access is either granted or denied.
3.3
Architecture for building secure profiles
An important security concern in the naive measurement of RTL is that it allows attackers to easily figure out the delay by simply pinging the server from the location of the user. If attacker learns the profile parameters of a user and if she is in a location with RTL less than that of the user, she can easily mimic the profile of the user by adding appropriate delay before acknowledging the profiling signals. To address this important security concern, CLAS introduces a special network component called Stealthy Relay (SR) in the round trip route between the user and the server (Fig 2). SR is a secure one-way packet forwarding device that is owned and controlled by the service provider. It is dedicated to receive profiling signals from the server and forward them to the user. The server encrypts each profiling signal with the symmetric key it shares with the SR. The SR then, decrypts the profiling signal and relays it to the user. The user sends an acknowledgement for each received profiling signal directly to the server. The relay functionality of the SR hides its existence and makes the user believe that she is directly interacting with the server. Moreover, the SR is installed in a separate dedicated secure network segment and does not respond to any other communications (e.g., ping requests), that is, attackers cannot connect to the location of the SR nor can they compromise it. Finally, the service provider may setup more than one SR at different locations for the purpose of load balancing and recovery form loss. To reduce the deployment cost of multiple SRs, service providers could utilize existing infrastructures, for example, Google may use its many offices, repair branches, or data centers to deploy multiple SRs. With multiple SR deployments, service providers can proactively change profile parameters by changing the user-SR assignments to guard against potential leakage of profile parameters. The purpose of SR is to make it extremely hard for any entity, including the users themselves, to learn the RTL. In Figure 2, the RTL is the sum of the delay over the pathsegment from server to SR (Dss ), the delay over the pathsegment from SR to user (Dsu ), and the delay over the pathsegment from user to server (Dus ). There are two possible ways for attackers to estimate the round trip profile parameters: (i) establish round trip cycles on the Dsu and the Dss path-segments by pinging the user and the server from the location of the SR. However, this is not possible because the SR is a hidden entity that only relays profiling signals
from server to users and it is assumed to be secure and connected to a location that is not accessible to attackers. (ii) An insider who has access to the location of the server may monitor the profiling signals and the acknowledgments to estimate profile parameters. This is thwarted by encrypting the profiling signals at the server before sending them to the SR, that is, the insider cannot map the incoming acknowledgments and the outgoing profiling signals, and hence, cannot correctly compute the RTL.
3.4
Profiling sample size and decision algorithm
Real-time profiles are established with every login, therefore, it is important to find the appropriate number of profiling signals that strikes the balance between profile accuracy and login latency and bandwidth overhead. Assume a population with Gaussian distribution that has standard deviation S and mean M . The goal is to find the minimum sample size, N , that produces a mean, µ, within a certain error margin, δ (aka, error tolerance, ET ), with a certain confidence level 1-α. For Gaussian distributions, it has been shown ([2] [3]) that the minimum sample size N (i.e., the number of profiling signals) can be calculated as: N ≥ (Z1−α /δ)2 S 2
(1)
Where Z is the critical value for the normal distribution. In other words, for a sample size of N , we have 1-α confidence that the measured mean (µ) will fall in the range of: M −δ ≤µ≤M +δ
(2)
Similarly, the range of the real-time measured standard deviation σ can be computed using Chi-Square (χ) table as: s s χ2L · S 2 χ2R · S 2 ≤σ≤ (3) N −1 N −1 Where χL and χR are computed for specific values of α using the Chi-Square table. The decision to grant or deny access for a certain login attempt is simple: if the measured real-time mean is within the range defined in (2) and the measured real-time standard deviation is within the range defined in (3), access is granted, otherwise, access is denied.
4.
EVALUATION
In this section, we evaluate the performance overhead and the security guarantees of CLAS. Specifically, our evaluation focuses on the following metrics: • False negative rate (F N ): The probability that a legitimate user fails to login from her profiled location. • False positive rate (F P ): The probability that a perpetrator who possesses legitimate user credentials authenticates on behalf of the legitimate user. • Login latency overhead: The extra time it takes a user to successfully authenticate using CLAS compared to a baseline system that authenticates using only username and password. • Bandwidth and storage overhead: The extra network bandwidth incurred and the extra storage required by CLAS. CLAS mainly has four parameters; the error tolerance (ET ), the maximum number of login retries (LR), the server workload (W L) in terms of login requests per second, and the number of profiling signals per login attempt (N ).
4.1
Experimental setup
We build a password-based web login service that supports CLAS authentication. The service is implemented using HTML and PHP and runs on an Apache HTTP Server Version 2.4. The server runs Ubuntu 12.04 LTS 64 − bit operating system, with 8GB memory, Intel i7 CPU ×8. The client population consists of 10 instances of Amazon EC2, 130 PlanetLab nodes, 25 GENI nodes, and 63 residential WiFi users. The EC2 instances are used to create the appropriate server workload. To measure F N rate, we set each of the 25 GENI clients to login 300 times during an hour period. The F N rate is computed as the number of failed login trials divided by the total number of login requests. To measure F P rate, we create and profile a different user account for each of the 160 clients. Then, we set each of the 25 GENI clients to play attackers’ role who try to login using the credentials of the remaining 159 clients. Each attacking client launches 300 attacks against each of the remaining clients. Therefore, the total number of attack instances is 1,192,500 (159 · 300 · 25). The F P rate is measured as the number of successful attacks divided by the total number of attack trials. In all the following experiments, unless otherwise stated, we use N = 91, W L = 200 requests per second, LR = 3, and the login occurs during weekday time periods.
4.2 4.2.1
FN and FP trade-offs Varying the number of profiling signals (N ) and error tolerance (ET )
Figure 3 shows the ROC (receiver operator characteristics) curves of the F P and the F N when varying ET while fixing N to 27, 54, and 91. The figure clearly shows negative correlation between F N and F P as a function of the error tolerance while both F P and F N improve (lower values) as N increases. The figure also shows that CLAS can achieve F P as low as 0.0017 while F N is below 0.007.
4.2.2
Varying the maximum number of login retries
Figure 4 shows the ROC curves of F N and F P for different values of ET while fixing LR from 1 to 5. The figure, intuitively, shows that LR has more impact on F N compared to F P . The chances that the legitimate real-time profile parameters match the profiled parameters in a next login trial is way higher than the chances of a perpetrator’s real-time profile parameters match the legitimate profiled parameters in the next trial. The figure also shows that LR of 3 provides the best trade-off between F P and F N because the impact of LR on the trade-off diminishes with higher LR values.
4.2.3
Varying the server workload (W L) Figure 5 shows the impact of the server workload on the trade-off between F P and F N rates. The figure shows small variations in F P and F N rates when the workload varies. In general, as the workload increases both F N and F P rates slightly increase. The variations are mainly due the slightly extra delays at the server when sending the profiling signals, receiving the corresponding acknowledgments, and computing the real-time profile parameters. 4.2.4
Varying the login time period
We also study the impact of the login time period on F N . We set each of the clients to login for 300 times during 4
different time periods. For the sake of brevity, we did not present the results. The results show that, in general, the F N is almost stable irrespective of the login time period. However, F N is slightly higher during the weekday due to the impact of peek time on network communications latency.
4.2.5
Residential user study
Figure 6 compares F P and F N ROC curves between two user types (residential and fixed). Residential users usually have less stable connections compared to enterprise and cloud users due to varying traffic and congestion of the last wireless hop. In this experiment, 63 residential users in Canada and USA use CLAS to authenticate to our testbed web-service over a one month period using home/work WiFi connections. The figure shows that the average F N rate of residential users is slightly higher than that of fixed users for the same average F P rate.
4.2.6
Impact of the WL on profile parameters
Figure 7 shows the empirical cumulative distribution function (CDF) of the relative maximum variations in mean and standard deviation of profiles for 25 GENI clients when varying W L from 1 to 300 requests/second. For each client, the relative maximum variation in the mean is computed as the percentage of the maximum variations in the mean relative to the average mean across all server workloads. Similarly, the relative maximum variation in the standard deviation is measured as the percentage of the maximum variations in the standard deviation relative to the average standard deviation across all server workloads. The figure shows that more than 90% of the clients have relative maximum mean variations less than 6.5% of the average mean for different W L. These results explain the earlier behavior of F N and F P when varying W L (Figure 5).
4.3 4.3.1
Performance overhead Login latency overhead
In this experiment, we study the variations of the login latency overhead under different server workloads. The login latency overhead is defined as the extra time it takes a user to successfully authenticate using CLAS compared to a baseline system, which authenticates using only username and password. Figure 8 shows the empirical cumulative distribution function (CDF) of the login latency overhead for each server workload. The figure shows that more than 95% of logins have overhead latencies below 0.2 seconds. The results conclude that the login latency overhead is unnoticeable by humans and hence the performance overhead of our scheme is negligible.
4.3.2
Bandwidth and storage overhead
The bandwidth overhead is caused by the profiling signals and the acknowledgments of every login attempt. Each user’s profile requires N profiling signals and N acknowledgments per login attempt. The size of the profiling signal/acknowledgment is about 50 bytes including all the headers. Therefore, the bandwidth overhead is 50 ∗ 2 ∗ 91 = 9100 bytes for N = 91, which is negligible given the fact that login bandwidth consumed by most of the popular websites (e.g., Chase.com, Facebook.com, Amazon.com) ranges between 10.98K and 125.47K bytes, according to a study that we have conducted on 12 popular web services.
0.014 N=27 N=54 N=91
0.014
Flase Positive Rate
Flase Positive Rate
0.012 0.01 0.008 0.006
0.024
LR= 1 LR= 2 LR= 3 LR= 4 LR= 5
0.012
0.01
0.008
0.006
0.004
0.004
WL = 50 WL = 100 WL = 200 WL = 300
0.022 0.02
False Positive Rate
0.016
0.018 0.016 0.014 0.012 0.01 0.008
0.002
0.002 0 0
0.006
0.005
0.01
0.015
0.02
0.025
0 0
0.03
0.02
0.04
0.08
0.1
0.12
0.004 0
Figure 3: ROC curves of F N and F P for various N , variable ET .
Figure 4: ROC curves of F P and F N for various LR, variable ET .
Residential Users Fixed Users
0.008
1
1
0.9
0.9
0.8
0.8
0.7
0.7
0.005 0.004
0.015
0.02
0.025
0.03
0.035
0.5
WL=1 WL=10 WL=100 WL=200 WL=300
0.6
F(X)
F(X)
Flase Positive Rate
Mean Standard Deviation
0.6
0.01
Figure 5: ROC curves of F P and F N for various W L, variable ET .
0.007 0.006
0.005
False Negative Rate
Flase Negative Rate
Flase Negative Rate
0.009
0.06
0.5
0.4
0.4
0.3
0.3
0.2
0.2
0.003 0.002 0.001 0.002
0.1
0.1
0.003
0.004
0.005
0.006
0.007
0.008
0.009
0.01
Flase Negative Rate
Figure 6: ROC curves of F P and F N for fixed and home users.
0 0%
1%
2%
3%
6%
7%
8%
0 120
9%
Figure 7: CDF of variations in µ and σ; variable W L.
CLAS EXTENSIONS
CLAS has the advantage of being user transparent and has negligible overhead, which enables it to be smoothly integrated with other authentication schemes without introducing extra overhead or degrading system usability. More importantly, CLAS offers unique security features such as resiliency to Phishing, MitM, leakage by other verifiers, and social engineering, which may complement the security features of other authentication schemes. In this section, we discuss the potential integration of CLAS with other authentication schemes to offer more robust and flexible defenses against password compromise.
5.1
5%
X: Relative Maximum Variations of the Measured Mean/Standard Deviation (ms)
The storage overhead is also negligible. In addition to username and password, the credentials database stores, for each user, the profiled mean, the error tolerance and the standard deviation range. This overhead adds less than 32 bytes per user even when using floating point representation (8 Bytes) of profile parameters.
5.
4%
Mobility and legitimate login failures
CLAS identifies users based on the statistics of the network communications latency, which is highly dependent on the login location of the user. The current implementation of CLAS may fail in the case of mobile users. If a legitimate user logins from a location other than the profiled one, she may be denied access with high probability. Additionally, due to Internet instabilities, the user may sometimes fail to login from her profiled location. To handle the mobility issue and potential legitimate login failures, we propose to augment CLAS with out-of-bandchannels such as Emails or SMS messages. Users specify additional communication channels as part of their refer-
140 160 180 200 220 240 260 280 X: Login latency overhead compared to baseline authentication (ms)
300
Figure 8: CDF of login latency overhead; various W L; ET = 0.3 · S
ence profiles. These additional channels can be used later to deliver temporary authentication codes to users when logging in from new non-profiled locations or when the login fails due to network instabilities. Even though this proposal has marginal impact on usability because it is only used as a backup mechanism, it provides lower security guarantees because it is susceptible to the same vulnerabilities of multi-factor authentication mechanisms. Therefore, CLAS considerably strengthens authentication security for static users, while it maintains comparable security levels to those of the state-of-the-art mechanisms for mobile users.
5.2
Sample space
The sample space is the collection of all possible authentication credential combinations. The size of the sample space matters when un-throttled guessing attacks are allowed. This is not a security concern in CLAS because CLAS does not allow un-throttled guessing, that is, CLAS blocks the account after predefined number (e.g., 3, 5, etc.) of unsuccessful login attempts. More importantly, The attackers can not simply try all the possible combinations of profile parameters in CLAS because it is impossible for attackers to simulate latencies that are lower than their own. Nevertheless, for applications that may require higher entropy, we recommend to augment CLAS with browser fingerprinting. In CLAS, the sample space of the RTL profile parameters has an entropy around 18 bits according to [10] while browser fingerprinting has an entropy of around 18 bits [6]. Therefore, the combined sample space of the augmented CLAS will be sufficiently large (around 36 bits). In addition, the integration of CLAS with browser fingerprinting can also defend against attacks in which perpetrators, who possess the legitimate user’s credentials, login from her profiled location.
6. 6.1
DISCUSSION Remote access and access from profiled locations
In CLAS, if an attacker manages to remotely access the computer of the user, through for example infection via a Trojan Horse or some other malware, then attacker can simulate the profile parameters of the user. Additionally, CLAS cannot prevent attackers who may login to the targeted service (using legitimate user credentials) from the profiled location of the legitimate user. The first attack is too strong as it can bypass any authentication mechanism and hence is not a unique concern of CLAS. The later can be addressed by using the integration of CLAS with browser fingerprint as detailed in Section 5.
6.2
Network instabilities
Someone may raise the concern that network variations are unpredictable and that the network instabilities may limit the usefulness of CLAS. We acknowledge that network instabilities exist. To address this issue, we categorize the network instabilities into 3 classes, namely, instantaneous instabilities, long-term instabilities, and routing instabilities. Instantaneous instabilities are instabilities which lead to transient changes in network communications latency and hence only affect a few packets of the authentication packet stream. This type of instability is the most common case and can be resolved by removing the outlier delays before computing the mean and the standard deviation. Long-term instabilities are instabilities that stay long enough to affect the whole or most of the stream of authentication packets. This type of instability is a less common case and usually happens at the local network. CLAS can address this case by increasing the error tolerance of the user according to her historical records. In addition, long-term instabilities can be alleviated by establishing multiple profiles which is out of the scope of this work and we plan to address it in a future work. Routing instabilities are instabilities that result in permanent changes in network communications latency due to, for example, permanent network routing changes. It has been shown that most of the important IP prefixes have stable routes and that instabilities only exist in a small portion of the global Internet [11] [12] [13]. Their experiments show that the majority of routing information exhibits the same significant weekly, daily, and holiday cycles. More importantly, the experiments show that network instabilities exhibit strong periodicity. Therefore, CLAS can leverage these temporal properties and the strong periodicity of such instabilities to create long-term dynamic temporal profiles. Consequently, the impact of this type of network instabilities in CLAS is marginal. In the worst case, for those sudden, unexpected, significant and permanent changes, which are rarely incurred, users can use the login failure techniques discussed in Section 5 to rebuild their reference profiles.
7.
CONCLUSIONS
In this work, we design and implement a novel highly secure and usable authentication scheme (CLAS), which uses in addition to the traditional credentials, the round trip network communications latency to uniquely profile users. The novel architecture of CLAS makes its profiling parameters
robust and highly resilient to manipulation. More importantly, CLAS is completely transparent to end users. Finally, CLAS is complementary to the techniques developed for multi-factor authentication and can be easily integrated with other authentication mechanisms to offer more robust and flexible defenses against password compromise. We conduct extensive experiments and the results show that CLAS can achieve false positive rate as low as 0.0017 while the false negative rate is below 0.007. Additionally, the results also show that the login latency overhead and the storage and bandwidth overhead are negligible. In the future, we plan to augment CLAS with techniques that can deny access to perpetrators even when they possess credentials and login from the profiled locations. Also, we plan to leverage multiple RTL profiles per user to further alleviate the impact of network instabilities.
8.
REFERENCES
[1] Gmail: Detecting suspicious account activity. http://googleonlinesecurity.blogspot.com/2010/03/ detecting-suspicious-account-activity.html. [2] NIST, e-Handbook of statistical methods. http://www.itl.nist.gov/div898/handbook/. [3] Stat 300 materials 7-3a. http://flc.losrios.edu/˜eitel/ Stat%20300/S-300%20Main%20Web%20Page.htm. [4] Yahoo: “on-demand” password. http://yahoo.tumblr. com/post/113708272894/a-new-simple-way-to-log-in. [5] The Cyberwire: Breaking news from RSA. April 2015. http://thecyberwire.com/issues/issues2015/April/ CyberWire 2015 04 21.html. [6] P. Eckersley. How unique is your web browser? In Privacy Enhancing Technologies. Springer, 2010. [7] S. Gastellier-Prevost, G. G. Granadillo, and M. Laurent. A dual approach to detect pharming attacks at the client-side. In New Technologies, Mobility and Security (NTMS), 2011 4th IFIP International Conference on, 2011. [8] A. L.-F. Han, D. F. Wong, and L. S. Chao. Password cracking and countermeasures in computer security: A survey. arXiv preprint arXiv:1411.7803, 2014. [9] N. Karapanos and S. Capkun. On the effective prevention of tls man-in-the-middle attacks in web applications. In USENIX Security 14, 2014. [10] M. Kwon, Z. Dou, W. Heinzelman, T. Soyata, H. Ba, and J. Shi. Use of network latency profiling and redundancy for cloud server selection. In CLOUD. IEEE, 2014. [11] C. Labovitz, G. R. Malan, and F. Jahanian. Internet routing instability. Networking, IEEE/ACM Transactions on, 6(5):515–528, 1998. [12] J. Rexford, J. Wang, Z. Xiao, and Y. Zhang. BGP routing stability of popular destinations. In ACM SIGCOMM Workshop, 2002. [13] A. Shaikh, A. Varma, L. Kalampoukas, and R. Dube. Routing stability in congested networks: Experim. and analysis. In ACM SIGCOMM, 2000. [14] S. Srinivas, D. Balfanz, E. Tiffany, and F. Alliance. Universal 2nd factor (u2f) overview. FIDO Alliance Proposed Standard, 2013. [15] V. A. Vallivaara, M. Sailio, and K. Halunen. Detecting man-in-the-middle attacks on non-mobile systems. In CODASPY. ACM, 2014.
