The Source Port is Georgia Tech's monthly cybersecurity newsletter, featuring commentary from its researchers about topics in the news over the past month, what wasn't written between the lines, the big (and sometimes nagging) questions driving our research, and new projects underway.
SQRL Authentication Promises a Single-Password World
Computer security expert Steve Gibson has recently released an early implementation of his Secure Quick Reliable Login (SQRL) authentication scheme. Explained as "an open, free, intellectual property unencumbered, complete and practical system to cryptographically authenticate the identity of individuals across a network", SQRL promises to provide single-factor login without requiring management of usernames and passwords.
IISP Analyst Joel Odom: Those who follow Steve Gibson's work will agree that SQRL has been a long time in coming. I've spent some time recently diving into the SQRL particulars and exploring the Windows client. I'm impressed. SQRL is a single-factor authentication solution that allows you to log into a website or a server using the SQRL client that is running on your local computer or on your mobile device. When you visit a website that supports SQRL, you simply choose the option to log in using SQRL, which triggers your local SQRL client to prompt you to enter your SQRL password before it authenticates you to the website. This SQRL password is the only password needed.
That's pretty much all there is to using SQRL, though there are a number of nice bells and whistles associated with the technology. Instead of reviewing all of the convenience features, I'll comment on some of the security-related features. First of all, there is a quick password feature that allows you to log into a website by only typing a few characters of your password. This is a carefully-considered convenience. If the quick password is entered incorrectly even once, the SQRL client automatically requires a full password. The quick password also expires after a short length of time, and is of tunable length. SQRL key derivation is done correctly, using a memory-hard password-based key derivation function, making brute force attacks difficult. Screen darkening mitigates attacks that could trick users into entering their password on malicious websites that mimic the client, and SQRL identities can send various options to
websites to pin policies that prevent attacks on account recovery and that thwart attempts to "downgrade" to using other authentication methods.
Although there is a mature developer community working to extend the SQRL ecosystem, the protocol and its clients are new. I'll venture to guess that some weaknesses will be found in the protocol, but I expect the first attacks on SQRL to be on SQRL implementations as experience has shown that implementations of cryptography are often the weak point. The SQRL client does smart things, such as encrypting data at rest and clearing sensitive data from memory when the data is not needed, but software is hard to secure and is prone to fail in unexpected ways. Attackers will eventually find some way to cheat, and any attacks discovered against SQRL and its implementations on the client and server sides will only get better. Still, my impression so far is that SQRL and the Windows client are mature enough for initial deployment.
There are a few other security thoughts that I've had about SQRL. Although the "SQRL Explained" document says that SQRL provides no centralized point of failure (no third party service is required), the technology itself is a single point of security failure, and it's unrealistic to expect that it won't need some improvement over time. Also, as far as I can tell, SQRL still requires TLS to authenticate the web server to the client, otherwise an authenticated session could be taken over by an attacker with network control. Of course, the same thing would be true of an attack on any authenticated session, regardless of how the authentication took place. Lastly, authentication only verifies the SQRL identity, not the real-world identity. Anyone could create a SQRL identity under the name Joel Odom. Again, this is true of most authentication schemes, but it's a subtle point that is sometimes overlooked.
I'm excited about this technology. It's a solid attempt at better authentication, and adoption should be straightforward because the destination website does not rely on a third party service. This is my first dive into the technology, and I'd appreciate any feedback on anything that I've misunderstood or left out. Twitter @joelodom is a good way to get that feedback to me.
Who is the Victim of Ransomware?
In the past month, two Florida towns have been hit by Ransomware attacks that crippled their computer systems[1, 2]. Both towns chose to pay the multi hundred thousand dollar ransoms, and it appears that both were given the proper decryption keys from the attackers and are in the process of recovering their computer systems.
Ransomware is a type of malware that encrypts all documents on a computer. The malware distributors then demand a ransom from the victim in exchange for recovering the files. If the ransom is not given, then the files are, for all practical purposes, lost.
IISP Analyst Kennon Bittick: Ransomware has had a slight lull in news coverage after a series of high-profile attacks (including one against Atlanta in early 2018). However, it is worth remembering that attacks are still prevalent and can be devastating. Ransomware causes permanent impacts by making critical data inaccessible and temporary impacts by bringing down computer systems until the malware can be contained. To avoid Ransomware attacks, it is important for organizations to practice good security hygiene to reduce the likelihood of an infection.
An interesting aspect of Ransomware is how local governments often seem to be the targets. Unlike attacks on most corporations, attacks on a city can directly cause life-threatening issues. In the most recent attack on Riviera Beach, the fire department and police were on separate networks and were not affected, but the 911 dispatch capabilities were hindered by the attacks. The fact that Ransomware can have a direct impact on life-safety changes the questions about whether to pay the ransom and how much time and money to spend on computer defenses.
Victims of Ransomware attacks have to decide whether or not to pay the ransom to the attackers. The FBI recommends not paying the ransom, and there are many reasons not to: paying the ransom encourages the attackers to continue their attacks, and there is no guarantee that the attackers will actually provide the decryption key when paid. On the other hand, the lost data or computer systems may be worth far more than the ransom amount, especially if the affected computer systems are preventing critical services from operating.
Of course, the best solution to Ransomware is to prevent it from infecting a computer system in the first place. The usual recommendations for security hygiene apply: ensure software on all computers are fully patched, deploy network-based and endpoint protection software, educate end users on phishing attacks (both Florida attacks resulted from a user downloading malware from an email), and use the principle of least privilege on user accounts to prevent damage from spreading if an infection does occur. When analyzing the cost of securing a computer system versus the risk of a Ransomware attack, particularly for governments that operate life-critical services, it may be that spending more on security is the smart move.