Forem: Tari R. Alfaro

Preventing malicious authentication attempts while avoiding CAPTCHAs.

Tari R. Alfaro — Sat, 08 Jun 2019 01:39:11 +0000

It's imperative that we protect credentials with great care, such as properly hashing the low entropy secrets with algorithms like Argon2 or Scrypt.

Multiple factors of authentication is important to protecting accounts. Such as having knowledge of a secret and in possession of something.

Despite properly implementing cryptography and management of credentials, there are still issues such as malicious third-parties attempting to gain access to accounts. And it's hard stopping that all together.

Just use CAPTCHAs! Hold your thought on that.

Usually it's still possible to attack a lot of services by trying well known "secrets" against a bunch of accounts. Some services attempt to prevent this with CAPTCHAs(official site).

One thing I've noticed is that CAPTCHAs are either accessible or sufficiently resistant to automated actions. Often it's not both. Sometimes it's neither! Even though I don't have any disabilities, I still have a hard time completing them.

Google's reCAPTCHA a lot of the time doesn't like Tor network activity often rejecting valid CAPTCHA answers due to "possible automated queries". Usually the solution I found is to switch up the exit node. It's an issue with popular proxies and VPNs, not just Tor users. More information here.

Unfortunately I don't know of any decent free open-source privacy respecting alternatives to Google's CAPTCHAs.

So CAPTCHAs may not be the best choice.

My solution.

The foreign account.

For each set of credentials that is stored, there is also a unique foreign account associated with it, this could be a email, XMPP or phone number that the authentic individual is in possession of.

The data.

There has to be some sort of data sent to the foreign account to prove they have access to it. The data MUST be ephemeral and random. This could be a software token attached to a link where a few authentication attempts are permitted. Or a secret(e.g: 8 digit code) that can easily be typed in.

To securely store the data, and verify the foreign account access data, it must be hashed properly. Generally the secret is low entropy, so we should store it with Argon2 or Scrypt.

However if the data comes from a CSPRNG output with >= 128 bits of entropy, we use an easy to compute hashing function. Take the BLAKE2 hashing algorithm for example.

For defense in depth or as an alternative strategy: Use asymmetric cryptography to ensure only the authentic individual may access the data. This could be sent to the associated foreign account or given right away.

Example secret(easy to type in):

8 1 7 1 5 9 4 6

Example link(far less guessable):

https://application.network/authenticate/d96c7bf0c9faf4c2c80a2d7e087aa258

The locking mechanism.

Now that there are two very important pieces to the puzzle gathered, that being the foreign account and the data. We have one final piece to gather.

What are we going to do with those two pieces? They can be used as a form of two-factor authentication.

By definition "locking" means to apply that 2FA. Of course we could constantly apply it(preventing nearly all malicious authentication attempts), however ... we can try to make educated guesses to only apply the 2FA when it's possible there is an attack on the account.

Which means it's possible to make the accounts a lot more secure while retaining usability.

What do we lock, when and for how long?

We can lock an IP that attempted to authenticate and failed a certain number of times within a certain time period. If we lock an IP, it's global. Meaning that IP is not allowed to attempt to authenticate on any accounts without verifying foreign account access. This goes for whitelisted IPs as well.

There is one other way to handle IPs. Each account could have whitelisted IPs that avoid the lock(only if the whitelisted IPs aren't locked), while any unrecognized IPs are automatically required to go through lock, even if the IPs themselves aren't locked. This could provide some better security while still retaining some usability.

Another method is locking by account. If a certain number of authentication attempts fail within a certain time period, it'll be locked. Meaning no IPs may attempt to authenticate on this account. That includes whitelisted IPs.

The only effective way of defending against attacks is to use both methods. Locking by IP and account, preferably with the same allowed authentication fail attempts before locking.

We can't completely rely on the first method because most experienced attackers know that they can just switch up their IP with a proxy.

We also can't completely rely on the second method because one IP could just attack all of the accounts. Instead we use both methods to prevent both issues.

However it's better to only have the second method than to only have the first. And it's best to have both.

If an account is allowed 3 failed attempts within 24 hours, and an IP is allowed 6 failed attempts within 24 hours ... they can use one IP to attack two accounts.
If an account is allowed 6 invalid authentication attempts within 24 hours, and an IP is allowed 3 failed attempts within 24 hours, we can use two IPs to attack one account. This can be worse than 1) because more attempts are available to each account.

For how long the account or IP is locked could fixed, incremental(depending on how many times it was previously locked), or randomized.

There are a few other things to take into consideration. You could make accurate educated guesses by determining how many requests there are to authenticate with which IP, and which account. Monitor and automatically lock all accounts for a certain period of time if you're 99% sure there is a possible attack on a bunch of accounts and warn the users that there is probably an attack that was prevented.

It's one area I'm still exploring, how to accurately determine whether there are attacks ongoing. (Although from my understanding it's extremely hard, it would require a lot of math, possibly even an AI.)

This was my alternative for authentication forms. This isn't meant to replace CAPTCHAs, it's meant to avoid them as much as possible and provide a more secure and accessible solution when authenticating.

The most secure solution is to always apply the 2FA, use asymmetric cryptography and a high entropy piece of data, such as the software token attached to a link. But this is too inconvenient for average users.

Take note that if you're not already logged into your email assuming that's what you use for the foreign account, then the email service could require CAPTCHAs during the sign in process.

If you have any questions or you'd like to discuss anything, contact me via email, Mastodon, the forum, DEV.to or XMPP.

Cross posted from here.

Block malicious login attempts, but preventing account lock-outs.

Tari R. Alfaro — Tue, 07 May 2019 00:07:11 +0000

How would you prevent malicious login attempts?

I'm curious how the DEV developers(those interested in security) here would prevent malicious login attempts.

My solution.

If a IP(e.g: 127.0.0.1) had failed to authenticate 3 or more times within a 12 hour period, block any further login attempts for 24 hours. This is global, this IP may not attempt to login to any accounts, not just that one account.

If 3 or more IPs have exceeded the 3 failed attempts on a specific account, all IPs are required to supply the federated account, on that specific account.

During those 24 hours of "blocked" login attempts, they are required to supply the account's federated account, such as an email(e.g: you@mail.com).

If they supply the correct federated account, email in this case, the server will send a special randomly generated link to you@mail.com that email that temporarily lets you bypass the blocked login attempts.

That link is valid for a short amount of time, e.g: 5-15 minutes.

You provide your credentials and you're logged in. However if the credentials are invalid twice, set a cool-down time of 60 minutes before another link may be sent.

If the attacker has access to your email, then you have a lot more problems. But this thwarts brute-force attacks directly against your credentials, while still being able to gain access to your account.

Remember, the goal is to prevent malicious third-parties from attempting to gain access to the account, while not blocking access for the actual people.

Be educated about today's security.

Tari R. Alfaro — Thu, 02 May 2019 01:51:28 +0000

Disclaimer: Security is a moving and vast subject. Stay updated! What is secure today could be insecure tomorrow.

Second disclaimer: Sorry for any errors in this post. It's really long, and I'm not a editor.

Links could be broken in the future.

Security has many sub categories, and it all really depends on what the context is. It is probably one of the most complex subjects of today. I will cover a lot of topics in this article, but not all. Security is extremely vast, there is more to it than cryptography.

If you're a developer, take a web application security quiz, and look at some cryptographic right answers.

Security is important, spread the word, participate, share your knowledge(preferably without being rude).

I go over some myths, attack vectors, best practices and resources.

Alright! Let's go over some myths.

Yep, myth busting time.

"VPNs provide anonymity." (No, they don't.)

Private Internet Access says:

Private Internet Access® VPN Service encrypts your connection and provides you with an anonymous IP to protect your privacy.

ProtonVPN says:

Keep your browsing history private. As a Swiss VPN provider, we do not log user activity or share data with third parties. Our anonymous VPN service enables Internet without surveillance.

NordVPN says:

Imagine VPN as a hack-proof, encrypted tunnel for online traffic to flow. Nobody can see through the tunnel and get their hands on your internet data. NordVPN gives you peace of mind each time you use public Wi-Fi, access personal and work accounts on the road, or want to keep your browsing history to yourself.

Nothing is hack-proof. No one is 100% anonymous. VPNs do not provide anonymity. VPNs see everything your ISP does. The question is, do you trust your VPN provider more than your ISP? VPNs are great for bypassing censorship and preventing ISPs from seeing requests you make through the internet.

It's good practice to use a VPN to encrypt your internet traffic when you're using public WiFi.

But Tari, VPNs mask your IP!

Yes, I know that. But that's not the only factor in obtaining anonymity.

If you're looking for anonymity, check out Tor Project and I2P.

"I don't need anti-virus on a UNIX-like machine." (Yes, you do.)

Just because you are using a UNIX-like machine does not make you immune to virus. Generally it's less common for there to be viruses for them, mostly because a lot of viruses are targeting Windows and MacOS users. I am referring to desktop use, not servers.

This does not mean anti-virus programs are a silver-bullet. Don't click on those phishy Facebook messages with "Check out yourself in this YouTube video!". Don't. Click. Random. Links.

Check out ClamAV.

Common sense is important!

"I am not important, hackers won't target me." (Yes they will, speaking from experience.)

Often, many people have many accounts on the internet for many services. Hulu, Netflix, banking, etc.

Banking is sensitive. Some people have bank accounts, with money in them. Why wouldn't a hacker want your money, or your credit card information? Or your Amazon account to buy stuff?

True story, my Mom's Hulu account got attacked by a malicious third-party. And my Dad's email and Amazon account were breached. Yes, this was recent, only a couple/few months ago.

"I must trade my privacy for security." (No you don't.)

Privacy is a category of security. Cryptography helps maintain your privacy. Conversations between you and your therapist are supposed to be confidential, private, secret.

Definition of confidential ...

Cryptography can be used in a way to ensure that secrets stay secret(Or private things stay private).

Example

Let's say you're signing into a service. They log your IP, user agent, device, etc. It's stored in plaintext. NO! They could encrypt it so only you could see the list of authenticated IPs and user agents. They could also hash them, and compare. If they don't match, send information saying that potentially there is a suspicious authentication action going on, and require additional authentication factors for that session trying to sign in.

Privacy is not anonymity!

Moving onto attack vectors and vulnerabilities.

This section is geared towards developers. There are so many attack vectors. I will only be going over a few.

SQL Injection; XML External Entities; Session Fixation; Weak Session Identifiers; Cross-Site Request Forgery; Cross-Site Scripting; Reflected Cross-Site Scripting; Command Execution; Click Jacking; Directory Traversal; Document-Object-Mapping Based Cross-Site Scripting; File Upload Vulnerabilities; Broken Access Control; Open Redirects; Unencrypted Communications; Data Mismanagement;

XXE/XEE. Read more ...

XML has some security issues. Things like XML External Entities (XXE/XEE) are possible.

XSS. Read more ...

There is more to Cross-Site Scripting (XSS) than simple alert(1). Much more. It is a complex subject, issues like these are STILL around today. Because there are different parsers for JS, HTML, CSS, that means they parse things differently from each other. And that means it can be hard to push security updates.

This is a parser differential issue, and there are many different ways to attack different browsers.

This post is already really long. Learn to mitigate XSS.

SQLi. Read more ...

SQL Injection (SQLi) is for the most part solved. It's mostly due to legacy projects. However vulnerabilities still popup, but they are usually spotted and patched quickly.

Make sure to use prepared SQL statements to avoid these issues.

Session fixation. Read more ...

The most common place for session identifiers are usually in cookies. Things like XSS can extract the session identifier IF the flag http_only is set to false, well, as far as I know.

If anyone has this, they can be logged into your account.

Make sure only HTTP may access the session identifier cookies. Destroy XSS vulnerabilities.

Don't store session identifiers in JavaScript localStorage! No, I don't have a solution/alternative other than build a native desktop and mobile applications.

Weak session identifier. Read more ...

A low entropy/easily guessable session identifier makes it easy for attackers to pose as an authenticated session.

The solution would be to create a CSPRNG 256-bit session identifier. The attacker would have to guess 2^256 possibilities, which would just take too long. Hash this session identifier, then store it on the client. Hashing it is important in case there was a issue with the CSPRNG.

Improper storage.

Not hashing the session identifier on the server could create issues. If a attacker breaches the server, they could be authenticated as any individual. In this instance, the server administrator is also the attacker, since they have access to session identifiers.

Hash the session identifier with a good algorithm. Preferably SHA2 family/SHA3 family/Blake2b. Yes! Hash it again here.

Cookie tampering.

Cookies are stored on individuals' devices. They have complete control over it. They can edit it, delete it, make cookies, etc. They cannot be trusted.

The solution is to use digital signatures to ensure that cookie values are not tampered with. If the value doesn't match up with the digital signature, report it, make it scream, AND DO NOT USE THE COOKIE VALUE.

Best practices.

Follow along with these best practices, and be sure to suggest these to your family, friends, acquaintances and strangers. This section is geared towards the average user.

Secure your passwords/passphrases.

You should be using diceware passphrases to protect your password manager, device login, and wherever else a password manager isn't appropriate.

Use a password manager.

You probably have lots of credentials. Use a password manager to secure your data. There are many of them. Stick with free open-source solutions because developers can verify the security of the applications.

I recommend KeePassXC for desktop, and KeePassDX for Android-based devices. There is also BitWarden.

Use multiple factors of authentication wherever possible.

Things like Hardware Security Keys, TOTP authenticator applications, email and SMS OTPs are great for securing your accounts. Use them wherever possible.

NOTE: SMS two-factor authentication is insecure, but it's better than no two-factor authentication.

Double check links.

Make sure you are double checking links, and not trusting random ones at that. Do not click them if they seem suspicious.

Use anti-virus and firewall software.

Make sure to use anti-virus software on your systems, and a firewall too.

Stay informed and learn from good sources.

Do note that some(ahem, a lot) of these links are geared towards people who understand technical details about certain subjects. I am being vague for a reason, because the subjects vary.

All these I have personally been using for a while.

Don't be afraid. Share your thoughts and resources below.

Clients and Servers

Tari R. Alfaro — Tue, 23 Apr 2019 22:53:06 +0000

I think that we should be trusting clients more than servers to handle our data for us.

Servers should try to focus more on performance and availability rather than individuals' security. This does not mean to disregard security at all! This just means servers should focus on securing themselves and the communications between clients and other servers.

Clients should provide confidentiality, authentication and integrity with cryptography for the individual. The clients themselves could be cryptographically signed, free open-source software with reproducible binaries. Anyone with the technical skill can audit the source code themselves. And if it's community based, also contribute!

Most importantly, clients are local while servers are remote. Meaning it is typically a lot harder to directly attack clients rather than servers, especially if individuals protected themselves adequately. Some might be easy targets. It all depends. This makes it harder to attack a whole audience if there is no easy way to distribute their attacks to everyone.

If that doesn't make any sense, think of it like this. The attacker would need to create malware for a specific operating system. Some of the audience might be using Android, iOS, Linux, MacOS, Windows, FreeBSD, etc. That is only one variable, there are many more. I am sure there are ways to distribute malware to multiple OSs.

So again, this allows client developers to focus on individuals' security, such as automatic secure updates, hashing their passphrases and encrypting confidential data before leaving the device. While servers focus more on storing and structuring data, performance and availability rather than individuals' security.

No, this does not mean client developers should overlook performance or availability either. But you should trust clients more than servers with your data.

This does make the client developers a much larger target, and wherever their client source-code is stored. But that is why they should be cryptographically signing their software.

So what are your thoughts on this?

Passphrases and Key Files

Tari R. Alfaro — Mon, 15 Apr 2019 01:17:06 +0000

WARNING: Complex and vast subject.

You can use key files for both VeraCrypt volumes and KeePass databases to cryptographically secure encryption keys.

The user would upload a file or a few as key file(s), along side their passphrase.

Put aside the target audience, average Joe probably wouldn't want to upload key file(s) every time they logged in along side their passphrase.

I see this in one case where it helps.

The database gets breached and the attacker only has the hashes, but doesn't know if they used key files or not to use as a pepper for their passphrase. And if hashes were appended/prepended to the passphrase it would make it more secure, right?

For each file that the user uploads, we will hash their contents and append them to the passphrase when it gets hashed.

There is many ways we could go about it.

passphrase = passphraseHash(passphrase + key_file_hashes)

Note: If there is more than one key file, the order that the key files would go in matters!

From the way I am seeing it, it is a proper "pepper" since it's user provided, etc.

There is many possibilities. The key file could be obfuscated in a folder with 1000s of files.

Where else could this help? Where would this bring pitfalls?

Thoughts? Please share them!