Table of Contents
Email and password are two crucial pieces of data that almost every website or an app would ask you for in order to sign up. Most of those services save your email into their databases in plaintext and use it to send you
spam very userful information on a constant basis. Knowing your email also enables those services to assist you if you forget your password. So far so good, but what happens when someone hacks those services? Unfortunately, such incidents happen more often than many people expect.
Having your email stolen is unfortunate but having your password stolen can be more dangerous. That’s because stolen passwords may be used to impersonate the users for a long time after a hack, completely without their notice. Another problem with having your password stolen is the fact that people tend to use the same password (or a few variations of a short list of passwords) to log in to many websites.
I worked on many apps during my career and they all required sending user passwords to an API in order to open new accounts or to sign in to existing ones. What happened next is still a mystery for me. Sometimes this information is not public and sometimes no one is really interested in knowing that. Ideally, those APIs should never save received passwords in plaintext but, unfortunately, it happens a lot.
Those are big wealthy companies and even they tend to fuck up big time when it comes to storing passwords. When we write front end code, we usually assume that API is the ultimate source of truth and we should make client code as “dumb” as possible. It’s actually a good way of thinking about front end development because, in most of the cases, there is often nothing we can do to fix server errors without modifying server code.
Well, it turned out, there is something we can do to prevent password leaking: just don’t send user passwords to a server. Servers don’t need to know user passwords and if they don’t have this data, they won’t be able to leak it. Argon2 is a great password hashing function and we can just send Argon2 hashes of the original user passwords in place of the real plaintext passwords.
This idea seemed a bit controversial so I asked around on Cryptography Stack Exchange. I’ve got a few interesting replies and it looks like it isn’t something unheard of. It’s just not mainstream and it really helps to protect user passwords from a database hack.
Most ICOs are scams that prey on dumb people and Filecoin might not be an exception (I don’t really know), but I stumbled across their web site and I really liked the idea of using a distributed storage solution. No recommendations here, I have no idea if it’s even possible. I was just looking for a place for my data backups. I considered Amazon S3 Glacier initially but ended up picking Scaleway C14 Cold Storage.
I’ve been using Java for many years and there is nothing wrong with using it for most of the use cases. The problem is, I work on Android apps quite a lot and it’s a very fragmented platform. Developers are forced to use ancient Java versions in order to be compatible with as many Android devices as possible. Kotlin is a kind of “hack” that allows developers to use many productive language features that simply aren’t available if you use Java.
Another noteworthy thing about Kotlin is its native support for coroutines which makes front-end development much easier. Concurrency is hard and Java concurrency is not an exception. There are alternative solutions that allow developers to avoid using native concurrency API but they usually destroy code readability by turning codebases into a hacky mess. In my opinion, coroutines allow developers to produce concise, easy to read code that can be read top-down, like a book. I believe that’s a big advantage.
Those two selling points are enough to convince me to use Kotlin, at least on Android. Interestingly, Kotlin ambition seem to be much bigger than that. Kotlin Native, another interesting Kotlin initiative, had started to get some traction lately. I wouldn’t speculate much about this but I generally like the idea of sharing the “core logic” but doing UI via each platform’s native toolkit. Many companies tried to go cross-platform and the results were unsatisfying (DropBox, AirBnB, etc). The main reason, in my opinion, is a poor choice of language and attempting to create a cross platform UI (a la Silverlight many years ago).
Here is the example of a hybrid architecture that I find interesting, although it’s probably not production grade yet.
The future of Kotlin/Native is not certain but there are already a few great libraries that are compatible with it. When it comes to databases, many Android developers choose a library called Room. It works pretty well, which is a rare quality for a mobile ORM solution. The problem is, its scope is limited to Android.
That encouraged me to look for an alternative and I’ve decided to give SQLDelight a go. I must say, it’s probably the best ORM solution I ever saw. It doesn’t try to hide SQL queries and it validates them immediately as you type them, which means less surprises on runtime. All you have to do is to define your tables and queries and it will create all of the Kotlin mappings for you in a transparent fashion. I really like non-invasive libraries that give developers full visibility and control.
Interestingly, this library may soon support other SQL dialects. I’ll probably consider using it in some back end codebases too.
Koin is a lightweight dependency injection framework. I tried it on a back end codebase first and I really liked the results so I’ve decided to ditch Dagger in a few Android apps I work on and the difference is hard to exaggerate. Koin is much easier to set up and use and it’s also harder to mess up the configuration. Highly recommend.
Book: The Rust Programming Language
I like learning new stuff in daily “chunks”. It means, I usually have a few 40-minute breaks during my work day to learn something new about a selection of topics. One of the current topics is Rust and this book works great with such a schedule. It helped me learn a few new things about Rust and the ways to write more idiomatic Rust code. This book might be helpful for anyone who wants to learn more about Rust.
Book: Mobile Unleashed: The Origin and Evolution of ARM Processors in Our Devices
This book is mostly about the history of computing, although some of the information is still relevant. Reading such a book is a good way to understand the technical breakthroughs that underpin many consumer electronics products.
Book: Investigating Cryptocurrencies: Understanding, Extracting, and Analyzing Blockchain Evidence
Although this book is focused on how blockchains work and it explains some things about them very well, that’s not what catched my interest there. What I find most interesting about this book is the description of computer forensic experts’ workflow.
Book: Industrial Society & Its Future
Ted Kaczynski, better known as Unibomber, had a pretty consistent worldview and this book of his have a lot of interesting thoughts and ideas. It’s provocative, it’s radical, but it’s also quite an interesting read. It’s hard to understand most criminals and their motives. Sometimes I just wonder why would a person A do a terrible thing B, because it doesn’t make sense. This book more than satisfies all of the possible “why"s.
Bruce Schneier is a well known security expert who writes quite a lot on many security related issues. He has a newsletter but I’m not a big fan of this format so I was pretty excited to find out that Dan Henage had narrated Bruce Schneier’s newsletter for years. The link above contains a huge collection of Schneier’s newsletters in audio format.
Movie: Narcos: Mexico
Bingeworthy, as usual. I have nothing to add, really.
Movie: Better Call Saul
This movie also doesn’t need introduction and the new season started well above my expectations, which were pretty high, by the way. It’s a pleasure to watch, but, unfortunately, Netflix didn’t release the whole season in a single bundle so now I have to wait for new episodes. Very frustrating practice!