DEV Community: Franco Traversaro

Fantastic Passwords and how to generate them

Franco Traversaro — Mon, 19 Nov 2018 10:55:09 +0000

Password strength, password management, password memorization, password bla bla bla. We spend half a day writing (or saving in browser) password for any damned service we use online. And we always use the same passwords, because surely we know that is a bad (ugly!) habit, but we really can't memorize so many abstract things.

A lot of articles has been written ont this argument. A lot of good advices have been adviced. XKCD has suggested, in my humble opinion, one of the best methods to generate a single, long, secure password:

But still, this is a good method to remember... one? three? six? different password. If you try to set a different password for every service you'll quickly have a lot of possible permutations to remember: «So, for gmail was correct horse battery staple, for github wolf cucumber pencil mug, then for slack is penguin banana honey bacon? Or it was honey wolf banana honey?»

So, my personal solution is simple. Aren't we developers? Aren't we everyday managing algorithms? Aren't algorithms our daily tool to resolve problems? So, why don't we use an algorithm to generate a unique password for every site?

The algorithm has to be simple, because we'll have to run in in our brain. For example:

The first three letters of the second level domain, in NATO phonetic alphabet, camel cased
An open square bracket
The length of second level domain, in letters
The lenght of the first level domain, in number
A square bracket closed.

Obviously I've made up this algorithm for this post, so don't try it on my accounts! :-) By the way, it's complex but can be easily remembered, and generates different passwords for every site:

Site or service	Generated password
dev.to	DeltaEchoVictor[three2]
gmail.com	GolfMikeAlfa[five3]
github.com	GolfIndiaTango[six3]

And so on. Obviously everyone can improve his algorithm as he wish: adding other symbols depending on any parameter, inverting the order of characters, adding a simple Caesar encryption... There are no limits, just the mental complexity everyone decide is affordable.

For the most paranoid ones (and when we talk about security we surely should be all paranoid), the algorithm should be quite robust also if a single password gets violated. Il some bad hackers should violate github and in some way get our password, a human being reading GolfIndiaTango[six3] could understand the phonetical part, and think about the possibility of an algorithm approach, and try it on other services we use. I think it's a remote possibility, because it can happen only if someone is targetting exactly you, and normally this isn't the case. But still is a possibility, so every one must choose his algorithm carefully.

I've never read anything about this algorithmic approach, but I've not searched about either, so as we say in Italy maybe "I've discovered the hot water". But I really love reading your considerations about.

Private parts exposed in public

Franco Traversaro — Wed, 08 Aug 2018 17:36:19 +0000

It's said that a good object keeps private or protected his properties, so nobody can harm the business logic. It's a wise advice, indeed, but sometimes we want to break things: maybe we need to gain access of a private connection managed by an external library, maybe we just want to see the world burn. An example of the first case happened to me a lot of years ago, when I was working on a strange Wordpress integration: I needed the underlying mysqli connection, but it was stored in a dbh property of the $wpdb singleton of class \wpdb. I couldn't edit the class to make dbh property public, but I needed the connection. What to do? We all know that a private or protected properties cannot be accessed from outside the instance through -> operator! A $object->privateProp will always fail!

That's not entirely true. Quite, but not entirely. There's a little detail that I think it's not so known: the access control to methods and properties is done checking the context from which we are working. So, if we are inside a method of the class, we can access private or protected properties of any instance of that class.

Enough talk, let's do some code. Imagine that we have a third-party library, that we cannot modify, that do this kind of things:

// begin read only code

class DeepThought {
    protected $theAnswer = 42;
    private $theQuestion = 'How many roads...';
}

$singleton = new DeepThought();

// end read only code

We disperately want to know theAnswer: we know that is protected, so we can work on it. We know that a protected property can be accessed from extended classes, so we write this piece of code:

class Towel extends DeepThought {
    public static function getTheAnswer(DeepThought $instance): int
    {
        return $instance->theAnswer;
    }
}

echo Towel::getTheAnswer($singleton);

Do you see the magic? Towel extends DeepThought, so can legitimately access his protected properties. When we call Towel::getTheAnswer() we are in the Towel context, so $instance->theAnswer is also legit.

But theAnswer is merely protected, and we also want to know theQuestion, that's private. Extending the class we still have not access to private properties... we need a bigger towel! :-)

Reflection comes to the rescue:

$refl = new ReflectionProperty(DeepThought::class, 'theQuestion');
$refl->setAccessible(true);

echo $refl->getValue($singleton);

Note that Reflection works also on protected properties, but I've presented it last for the sake of narration. We just instantiate a ReflectionProperty for theQuestion: that's like a tool that can inspect or edit some attributes without changing the code. After we use the reflection to make the property accessible, and lastly we apply our edited property description to the original object. It's like .call() in JavaScript.

That's all! With these two techniques you can tear apart any class to extract the gems inside. But stay wise! Objects with private properties often have good reasons to be designed that way. No developer take care of backward compatibility for private properties: as in real life, if you play with other's private parts without consent you can get in trouble!

Catch the flag!

Franco Traversaro — Sat, 30 Jun 2018 15:04:09 +0000

Have you ever seen configurations written as a concatenation of constants? Something like error_reporting = E_ERROR|E_CORE_ERROR: what kind of sorcery is this? It turns out this is a real common (and smart) way to pack a lot of boolean flags into a single value.

So let's make something that use binary flags. I'll use PHP, but the concepts are applicable to any language with support of boolean bitwise operators. They're quite common, you'll admit. So, let's assume that we have a function that set the table when we invite our friends home for dinner. Sometimes we do a very special dinner with appetizer, first course, second course and dessert (I'm from Italy, so it's not uncommon), sometimes just a first course and dessert, sometimes any other permutation. So we do something like this:

function setTheTable(
    bool $appetizer = false,
    bool $firstCourse = false,
    bool $secondCourse = false,
    bool $dessert = false
): void
{
    if ($appetizer) {
        // do something
    }
    if ($firstCourse) {
        // do something
    }
    // here the others checks
}

Well, that's really ugly. If we need just dessert we must call an embarassing setTheTable(false, false, false, true). If we need to add support for a welcome drink AND coffee AND liqueur (Italy, remember?) we must add 3 others variables, all of them enqueued to the previous ones because we want backward compatibility... Really, a terrible solution. It could be better if we use a configuration structure, in PHP arrays are the best solution:

function setTheTable(array $conf = []): void
{
    if ($conf['appetizer'] ?? false) {
        // do something
    }
    if ($conf['firstCourse'] ?? false) {
        // do something
    }
    // here the others checks
}

That's better, but still kinda sucks. Now we depend on a bunch of custom strings: that's ok if the function is the only one that use them, but if some other parts of the project depends on them you can see the problems: string mispelled can bring bugs quite difficult to spot, and the IDE cannot help you. That's the work for constants, or enums, or other similar language constructs, but if we want to use an object instead of an array we could have problems using them. What a mess! We want just something really simple:

function setTheTable(int $conf = 0): void
{
    if (/* some magic here for appetizer */) {
        // do something
    }
    if (/* some magic here for first course */) {
        // do something
    }
    // here the others checks
}

But how can we achieve this?

The most important information you have to know is that a decimal number can be written in binary form. Here's a quick reference with the numbers we'll use in this article; I'll put also a decomposition, later you'll find why:

Decimal	Binary	Decomposition
1	`0001`	1
2	`0010`	2
3	`0011`	2 + 1
4	`0100`	4
5	`0101`	4 + 1
6	`0110`	4 + 2
7	`0111`	4 + 2 + 1
8	`1000`	8

Stick your attention to those number with no decomposition: 1, 2, 4 and 8. They are all powers of 2, and in their binary form we can find just one 1 and all zeroes. Keep in mind this detail: powers of 2 are important.

And now for something completely different whe must analyze what bitwise operators do on binary numbers, because they'll be the key of our flag system. We normally use boolean operators, like if ($a AND $b), that consider the operands as a whole boolean value: so we know that true AND false is false, true OR false is true, true XOR true is false, NOT true is false.

Bitwise operators do the same thing, but at a lower level, bit by bit. The notation is also different. C language has taught us to write & for bitwise AND, | for OR, ^ for XOR and ~ for NOT. So we can try a simple 0001 | 0010: we'll write in column, in order to make clear the idea:

0001 → 1
0010 → 2
0011 → 1|2 = 3

Do you see the logic? The operator has checked the first character of the two operands and applied a normal boolean logic: 0 is false, 1 is true, so false OR false gets false, a.k.a. 0; the second character is the same; the thirdth is false OR true, so true, a.k.a. 1; the fourth is true OR false, so another 1. Pretty simple, isn't it?

Maybe now you'll say "Ok, bitwise OR is an addition, because 1|2=3". Well, definitely no. Try 1|1:

0001 → 1
0001 → 1
0001 → 1|1 = 1

So, bitwise operators sticks to just one character at a time: the "addition" has not a "carry". Let's have another example, with bitwise AND:

0111 → 7
0101 → 5
0101 → 7&5 = 5

That's interesting: all the 1 in 0101 are paired with a 1 in 0111, so the result is another 0101.

We know (or you'll know in a few seconds) that 5 is deconstructed in 4 + 1, that is 0100 + 0001, because in binary numbers each character "gain" a value based on his position, in powers of 2, from right to left; we can write 0101 as 0*8 + 1*4 + 0*2 + 1*1, and if you strip off the 0 multiplication and simplify the *1, you'll get just 4+1. Pretty simple, isn't it? So we can say that "destructuring" is like an inversed bitwise OR, because 1|4 is equal to 0001 | 0100, that is 0101, our 5.

Now, take a deep breath. Try to call 1, 2, 4, and 8 with other names, like appetizer, firstCourse, secondCourse and dessert. So 5, 0101, is:

0 dessert (0*8)
1 secondCourse (1*4)
0 firstCourse (0*2)
1 appetizer (1*1)

They seems like flags, am I right? So we can try this approach (but remember, the values must be all non-zero differents powers of two):

// Constants declaration
define( 'APPETIZER',     1 );
define( 'FIRST_COURSE',  2 );
define( 'SECOND_COURSE', 4 );
define( 'DESSERT',       8 );

// Our beloved function
function setTheTable(int $conf = 0): void
{
    // here the checks
}

// Our business logic
setTheTable(FIRST_COURSE|DESSERT);
setTheTable(SECOND_COURSE);
setTheTable(FIRST_COURSE|DESSERT|APPETIZER|SECOND_COURSE);

That's good! Now we have constants that our IDE can recognize, the order of parameters is ininfluent, we can add whatever other value without breaking compatibility. We have just one limitation: we're using integers, so we have 32 or 64 bits available (the limits depend on language, architecture, seasonal weather, astral conjunctions and so on; RTFM is the only way to know the real limit). But if you're thinking about a function with more than 32 boolean switches you have more than a problem.

But... how can we check for flags? For example, the recurring 5, that we write as APPETIZER|SECOND_COURSE: we need to check if the APPETIZER is enabled or not. In other words, check if in the deconstruction of the configuration parameter we have the value for APPETIZER. That's a bitwise AND operation:

0101 → 5 → APPETIZER|SECOND_COURSE
0001 → 1 → APPETIZER
0001 → 5&1 = 1 → APPETIZER

And if we check for DESSERT? Let's see:

0101 → 5 → APPETIZER|SECOND_COURSE
1000 → 8 → DESSERT
0000 → 5&8 = 0 → we don't have a constant for that, so it's simply a false value

Cool! Now we can fill those "some magic here" comments:

function setTheTable(int $conf = 0): void
{
    if ($conf & APPETIZER) {
        // do something
    }
    if ($conf & FIRST_COURSE) {
        // do something
    }
    // here the others checks
}

Now that's pretty! Simple and concise. And now we can do some cool trick, like check any flag from a selection: we could check if we have appetizer or dessert or both:

if ($conf & (APPETIZER|DESSERT)) {
    // something
}

How does it works? First we calculate APPETIZER|DESSERT: 0001|1000 = 1001, and then we check if $conf has some 1 in common; let's see some examples with different configurations:

Literal $conf	$conf	Result	Literal result
`APPETIZER`	`0001`	`0001`	`APPETIZER`
`APPETIZER⎮FIRST_COURSE`	`0011`	`0001`	`APPETIZER`
`APPETIZER⎮DESSERT`	`1001`	`1001`	`APPETIZER⎮DESSERT`
`FIRST_COURSE`	`0010`	`0000`	–
`FIRST_COURSE⎮SECOND_COURSE`	`0110`	`0000`	–

So the result carry the information about which flag was effectively on. So we can also check that ALL the required flags are active:

if ((APPETIZER|DESSERT) === ($conf & (APPETIZER|DESSERT))) {
    // something
}

That's a little verbose, but if you do this check just once it's ok. But what if you do a lot of dinner with just first course and dessert, and a lot of complete dinner with all the components? Well, you can define derived constant!

// Basic constants declaration
define( 'APPETIZER',     1 );
define( 'FIRST_COURSE',  2 );
define( 'SECOND_COURSE', 4 );
define( 'DESSERT',       8 );

// Derived constant declaration
define( 'SMALL_DINNER',  FIRST_COURSE|DESSERT );
define( 'FULL_DINNER',  APPETIZER|FIRST_COURSE|SECOND_COURSE|DESSERT );

// We can use derived constant like any other:

if ($conf & SMALL_DINNER) {
    // we have a first course, or a dessert, or both
}

if (SMALL_DINNER === $conf & SMALL_DINNER) {
    // we surely have a first course AND a dessert
}

That's also convenient because now you can play with negations! Let's see:

setTheTable( FULL_DINNER & ~DESSERT );

How does it works? First let's see what's the value of FULL_DINNER: it's defined as APPETIZER|FIRST_COURSE|SECOND_COURSE|DESSERT, so it's 0001|0010|0100|1000 = 1111. After we do ~DESSERT, and it's ~1000 = 0111. The last step is the AND of those two values: 1111&0111 = 0111. We have effectively removed the dessert from the configuration, what a shame. Now, for just 4 flags it's not so useful, but try to think with a lot of flags, like in PHP, the configuration of error reporting: E_ALL & ~E_NOTICE is waaaaay better than listing all the other available levels. And if another level will be added in the remote future, the developers will take care of changing the real value of E_ALL, so your configuration will remain valid. This brings an important suggestion: never, never, never use directly the numerical values, use only the literal constants; numbers can change their meanings, on the other hand constants are, well, constants!

Just a last trick: if you prefer, you can write your constants directly in binary integer notation (if your language of choice supports it). When you'll get used with binary flags it will be useless, but at the beginning can make concepts clearer:

define( 'APPETIZER',     0b0001 ); // 1
define( 'FIRST_COURSE',  0b0010 ); // 2
define( 'SECOND_COURSE', 0b0100 ); // 4
define( 'DESSERT',       0b1000 ); // 8

This was just an introduction to binary flags; there are some interesting trick also while editing those values, but I'll think that for this article ça suffit. If these concepts will be usefull please let me know, this was my first article on dev.to and I'm craving for feedback!