A hacker’s guide to not get hacked

Assume you are a technically savvy person who knows the basics. You never install random crap from the internet. A typical phishing email makes you laugh, you almost pity the mankind which can be fooled by scammers as silly as those. Your phone screen is locked by default, and you use a password manager.

In multiple ways (sometimes inevitable, oftentimes obscure and cryptic) you depend on things (software, data, hardware) you do not own nor control locally (unless you are extremely paranoid and have accepted huge operational overhead). And I do not mean continuously bleeding “digital trail” of metadata and behavioural tracking. Let’s talk about a risk of being really hacked.

Understand (and prioritize) your assets


You obviously give the top priority to your bank accounts and launch codes, but some other things might be more expensive than you imagine at a first glance.
«There is nothing secret and I have all that information elsewhere» might lead you, in case of a loss event, spending a whole weekend handpicking it from… from said «elsewhere», and sorting everything in the precise OCDish way it use to be. Some other things may be of sentimental value and little interest to anyone but you certainly do not want everyone to see it (and you are likely underestimating the importance of your feelings, until said «everyone» see those files). You better archive all conversations with your ex-es and don't leave it hanging in your chat history (which would not help much unless other parties do the same). Ah, and, if you own some cryptocurrency, I hope you keep it on a local wallet, otherwise you do not really own it.

Understand (and prioritize) your attack surface.


A computer is not that unsafe unless you physically lose it (while having no disk encryption in place) or forgot (you did not, right?) to remove Adobe Flash from your system. If you adopted a good habit to handle MS Office and PDF documents with web-based services (as long as the content of said documents are not secret) you further improve the overall security of your local system.

Thus, your chances to get hacked via a 0day exploit (unless you do really store actual launch codes on your computer) are negligible.

Portable devices, I mean iOS and Android… Really, you cannot be serious. Android malware? Which requires your consent, like, three times to run, (ok, or just one if you have a system which is 5 years old with unpatched security bugs)? Again, your worst-case scenario always implies someone getting your device in physical possession.

Third party services (I want to avoid using the word “cloud” because the worst things aren’t even cloud, see below) are your only real concern. It is something completely outside of your control. It is not necessarily bad, but they may be vastly distributed, prone to breaches, accidental social engineering attacks and all those factors are unpredictable. To add insult to injury, they often actively encourage, just a little bit short of enforcing, “questionable" security practices. So the rest of the essay will be dedicated to them.

Build dependency graphs and rebuild it wisely



Here the hell begins. Common consensus dictates that the general public is totally incapable of managing their own access credentials without either losing access or leaking it to a malicious entity. Thus said, it all revolves around "recovery methods" which make your access credentials tightly interdependent and susceptible to a cascade failure unless you take special care of that. Let's do a simple dissection.

Worst of all is your phone number used for verification. Because the phone number is something you do not actually own in any way. Even the SIM card is legally the property of the cellular operator which provided it to you for lease (just like your bank card is). You do not own the number, you do not even own the network authentication key (try to reprogram or extract it!). As a practical consequence, not to mention slightly more complicated SS7 attacks, any cellular operator employee may issue a replacement SIM card on your behalf to anyone looking credible enough to them.

The funniest part is it is the sole ultimate trusted method for many services, including some banks, instant messengers and — Facebook. On Facebook, you cannot deny it from providing SMS recovery codes unless you remove the phone number from the system completely. Google is a bit less persistent, it just keeps whining about how insecure it is not to have an SMS recovery option.

Then there are email accounts. You may have multiple ones, you may consider different threat models which would either convince you to stay on Gmail (at least it is really hard to divert anything in transit there) or to use your own mail server (think BGP hijacks, domain hijacks, and all that nasty stuff, email is generally not designed to be very secure). Anyway, once one of your critical email accounts gets compromised, things can get very nasty. It is one more «recovery method» you often cannot simply turn off (and in most cases, you do not really want to).

There are social network logins. Not to mention the direct problems you would have, many services would let you in on email/phone match without additional checks. Say, if you log into Booking.com with Facebook, you do not provide any authorization on the Booking.com side to recognize your Facebook login: you just let Facebook share your email and phone number and you are instantly connected.

Security questions should be, without any doubt, nominated for one of humanity’s stupidest inventions. Just imagine how attractive would it be to give up access to your account to any person who happens to find out some trivial fact about you. Especially one of those facts you can find in a public database. Yet you can suppress your disgust and treat it as usual recovery codes. Make sure you use a decent random string generator. You may use questions that are really private — but they are non-reusable and you should keep that in mind.

To minimize dependencies and maximize security, you need to turn off all unnecessary recovery options (especially phone numbers), turn on a second factor (one-time passwords, definitely not SMS!), and generate recovery codes and store them in a safe place. Offline and on a hardcopy, preferably.

It does not guarantee anything. Security models for most of the services are incredibly stupid, because they are ad hoc and lack consistency from ground up. I designed a better one for a customer a while ago: it was simple as that:

* every authentication factor that is not under the direct control of the user is considered insecure
* no combination of insecure authentication factors may be ever treated as secure
* recovery procedures that rely on insecure factors should be implemented with extreme caution.

Is it hard to understand or hard to implement? No. Does it impair user experience? Unlikely. Yet it does not scale well enough for services with billions of customers, unfortunately for them. Therefore, when you accept Google or Facebook policy, you are solving their problem on your own expense.

Have a contingency plan


There are no silver bullets, and my advice are not panacea. Anything can fail. Be prepared.

Some useful links:
On second factor: ithipster.com/blog/unorthodox/34.html
On NIST warning not to use SMS: www.theregister.co.uk/2016/12/06/2fa_missed_warning/
On cascade failures in authentication: https://www.cs.uic.edu/~polakis/papers/sso-usenix18.pdf

GMOs And Passwords



Before you indulge into an experiment investigating the effects of whatever quality of a subject, it is the best for you to make sure beforehand that the quality in question does belong to your subject.

We colloquially say: «a red pencil» as if it is not a question whether a pencil can be red. Indeed, it can. In this particular case our «intuition» coincide with physical reality. We can create an experiment that demonstrates a possibility of any colour be a quality of a pencil. We can clearly define «red» as a specific feature of the light spectrum, and we can unambiguously link those spectra to each pencil. We can see (experimentally) that some pencils share this quality, while some do not. Even if the dividing line between these sets is fuzzy, we now have a CHARACTERISTIC PROPERTY of a «red pencil»: all red pencils share this property, and all non red do not have it. Facing a pencil, we can (experimentally) determine if it is red (and to what extent).

It is perfectly legitimate for anyone to call a pencil «red» or otherwise tag a pencil with a colour, because of the physics, not because the language allows it. Language is equally suitable for describing reality and nonsense as well. We still can call a pencil «aggressive» but it does not make physical sense. Aggressiveness can not be observed in pencils. There are many qualities applicable to pencils and there are many qualities inapplicable to pencils. Some qualities are plainly inapplicable to some objects — this fact is so basic that is often forgotten.

Now, I give you two grains of wheat, one is «GMO» and another isn't.
Can you conceive an experiment that tells me which is which?



Maybe it is time to make one step back and determine if «GMO» is a quality of an organism? Is there any CHARACTERISTIC PROPERTY of a «GM organism», something that all «GM» subjects share, while none of the rest have? Please, define this property for me. ...or simply ask yourself (every time you are looking for the magical label on the food package) what is this characteristic property I am looking for?

Now, as you have yelled at me all your suggestions, think carefully which of them is actually a property of an organism. Not single one. All that you have come up with are qualities of a production process or a design process or even earlier. None of those can be observed in a grain of wheat.

Observing a car, can you tell, for example, a difference between a car that was sketched with HB pencil and a car sketched with 2B pencil during their stage of development? In case of a car you would not claim that all qualities of a design phase are inherited by the product. You may consider me foolish to even suggest this very possibility. It is too obvious for you that a car and a car production process are two wildly different objects. Ok, then. What makes you claim that «GM» property of an organism design process is also a quality of a resulted organism? Hopefully you are not going to claim that organisms and their production processes are the same object.

However, you may legitimately conjecture that this particular property somehow translates from the design process to the organism. This is why I gave you these two grains of wheat. Take them and prove your conjecture. Show me the CHARACTERISTIC PROPERTY of «GMO».

I know you are wondering what all this nonsense has to do with passwords.
Well, this is all about the information entropy, which you do happily assign to your passwords without even a glimpse of doubt: IS IT REALLY A QUALITY OF A PASSWORD??? CAN I CREATE A CHARACTERISTIC RELATION THAT MAPS PASSWORDS ON REAL NUMBERS AND IS A FUNCTION???

Fingers vs Fingerprints



It turned out that my "Authentication vs Identification" article was not sufficiently conclusive in the sense that some hardcore biometrics fans still nurture a non-trivial and well justified objection. So I need to address and destroy it, in order to close the topic. My opponents' argument is:

Your analysis narrows the both sides of the problem to a knowledge/ownership claim. Even if you are right, the conclusion is only applicable to the authentication by means of a knowledge token, whereas all the rest relations between the user and the token (suitable for authentication purposes) are set aside. There is one particularly important relation (the one fundamental for the entire biometrics field): «the user is» or other way around «the token is a part of the user» — this relation implies inalienability which makes the token safe for authentication purposes.

It is true. Completely true. It is undeniably true! In the physical realm.
Read more →

Authentication vs Identification



Once again I have to return to the topic of strict antagonism between the authentication and the identification, meaning these very processes and the tokens involved as well. Before I indulge into boring you with tedious decomposition of entities you used to perceive as atomic, I present you a synthetic illustration of the difference in question. A bad guy tries to get a false-negative outcome of identification, and a false-positive outcome of authentication. This is not explanatory, yet very indicative, I hope it gives you an idea of the magnitude of the difference, and we are going to dig into this now.
Read more →

What Makes Your Password YOURS?



Simple questions are usually the most difficult ones to answer. And the most important among them are traditionally labeled stupid and dismissed. The modern days InfoSec is based upon unanswered questions. The lack of theoretical basis allows InfoSec gurus to produce teachings and «best practices» without a limit.

Today I want to address two very basic questions about passwords:

What are characteristic properties of a password? and what makes your password yours?

By answering these questions you achieve understanding of the utter malevolence of the password abandonment movements, that are so frighteningly popular today. There is a particularly dangerous movement to replace passwords with bio-metric attributes that can reliably identify your body (e.g. voice, fingerprints, and such). Although these attributes are successfully used in forensic practice for centuries, it does not make them good authentication tokens. Why? Because your password's job is NOT to identify your body.

I hear you screaming: «WHAT?!?!?!» That means you are ready to investigate what IS a password, what is its job, and what properties do you want your password to possess.
Read more →

An Observation About Passphrases: Syntax vs Entropy



I suggested in the article to use passphrases instead of «traditional» passwords, for multiple reasons, including: sheer strength, memorability, and conforming to idiotic password creation policies without actually following detrimental recommendations of the policy authors.

This recommendation gives rise to a reasonable doubt: «what if syntactically correct phrases are as weak as dictionary words in comparison to a random string of symbols?''. Indeed, syntax itself should weaken a passphrase, as it provides some „predictability'' to the phrase. I want to address this problem, by comparing syntactically correct passphrases to random collections of words (which we all consider sufficiently strong… hopefully).
Read more →

Password Strength Explained

This is a scheme of how we define password strength in a strict scientific manner without bullshit and lyrics:

1. we clarify what is a guessing attack and set aside all other types of attacks;

2. we prove the theorem: any two guessing attacks differ ONLY by the ORDER in which they try candidate-passwords;

3. we demonstrate that password strength (in any practical sense) is a function of an attack;

4. the strength of a given password is the position of this password in the attacker's dictionary;

5. the defender's strategy is an approximation of the attack dictionary order;

6. an approximate order is equivalent to a specific set of orders (i.e. different attacks);

7. thus, the defender's password strength is an expected value for the password strength over the given set of attacks.

You can read the implementation of this scheme in my paper: "A Canonical Password Strength Measure". It gives us a feasible meaningful unambiguous measure that everyone can implement.

It is also worth noticing that Shannon's entropy is entirely irrelevant to the password strength problem. Entropy is based on the ASSUMPTION of possible outcomes. This set is well defined in the context of measuring a memory size, and not defined at all in the context of password creation/guessing.

In contrast to my work, the «password strength» discourse is extraordinarily rich on bullshit. Take a look at this masterpiece. This is a great example of how to write some 35K of text without answering the question, and even without understanding the subject. Let me quote the key paragraph:

Password strength is a measure of the effectiveness of a password in resisting guessing and brute-force attacks. In its usual form, it estimates how many trials an attacker who does not have direct access to the password would need, on average, to guess it correctly. The strength of a password is a function of length, complexity, and unpredictability.

This is one of the best non-answers I have ever seen, and a very succinct one too. No wonder it originates from the government officials! It obscures the matter it addresses in almost every word — «effectiveness», «resisting», «complexity», «unpredictability» — what are they? So, essentially the quoted paragraph reads:

Password strength is a function of something unknown to us.

It is time for us to do some trivial maths and terminate the «password strength» nonsense.