I’m super excited to announce that my book, Password authentication for web and mobile apps, is out! I have a lot more to say about why I decided to write it and what the writing and publishing process was in future blog posts. Meanwhile, if you’re a developer who wants to understand password authentication and implement it for your web site or your app, please check it out: https://dchest.com/authbook/
The world’s most secretive technology company designs computers in such a way that their cameras cannot be covered with anything other than 0.1 mm thick stickers:
If you close your Mac notebook with a camera cover installed, you might damage your display because the clearance between the display and keyboard is designed to very tight tolerances.
Make sure the camera cover is not thicker than an average piece of printer paper (0.1mm).
I tried a few covers after switching to the 2018 MacBook Pro and couldn’t close the lid indeed (I’m glad I didn’t damage the display).
This is in contrast to Lenovo, who have built-in covers in some ThinkPad models.
Apple touts the green light indicator as the solution:
The FaceTime HD camera built into your Mac computer is designed with your privacy in mind and uses a camera indicator light that glows green when the camera is active. So you will always know when the camera is on.
Previous MacBooks had a software-controlled indicator that malware could turn off while secretly recording you. What’s great about new MacBooks is that Apple designed the camera in such a way that powering it will automatically power the indicator. If the camera is on, the light will be on as well and it cannot be disabled via software.
This is good, but presenting the indicator light as a privacy solution is missing the point of camera covers. This is like telling someone who likes to walk naked around their house to not close curtains if they are afraid of being seen by neighbors, and instead to rely on noticing if someone looks at them. Camera covers are like curtains — the user can be 100% sure that nobody sees them even if they accidentally enable camera during video chat. (Which is especially important given the state of video chat apps usability.)
It would be nice if Apple provided curtains (or the ability to install them) for our windows the next time they upgrade MacBooks. I don’t think it will ever happen, though. To be fair, webcam covers were always a hack.
You’ve probably heard of that thing that restored (well, tried to restore) pixelated images.
You may have heard about the criminal who got caught after he posted a swirled photo of himself. Police was able to undo the deformation to reveal his face.
Turns out, blurring can also be undone in some cases:
This is the result of Restoration of defocused and blurred images project by Vladimir Yuzhikov. Of course, it won’t magically unblur any photo, but the results are impressive nonetheless.
If you want to make something unrecognizable in a photo, just slap a big black rectangle on top. Make sure that the rectangle is opaque. Then take a screenshot of the censored image just to be safe and use it. To be completely sure, print and scan it back if you’re paranoid! Make sure your printer or scanner drivers don’t send pictures somewhere. Ah, screw it, just don’t post the picture!
SwiftUI is Apple’s UI framework, which is quite similar to React. It lives on top of their other UI frameworks: you declare components, state, and some callbacks, and the system will figure out how to render everything. It was announced last year. This year Apple improved it, added many missing features, and began using it for new widgets, Apple Watch complications, etc.
What’s interesting is that Apple is clearly going for the ease of cross-platform development. With the same UI code base, the same components adjust their behavior according to the target platform: watchOS, iOS, iPadOS, macOS, and tvOS. (glassOS in the future?)
In The WWDC 2020 Talk Show Craig Federighi said that they are not declaring a single framework a winner for the future, everyone can continue using UIKit and AppKit. This makes sense — for now — since you can do things with them that are not yet possible to do with SwiftUI (and vise versa since iOS 14). But to me, SwiftUI seems like the future of development for Apple’s platforms. It’s easier to write and understand, it can be more performant, and more importantly, Apple has more control of the final result due to its declarative nature.
I don’t expect them to abandon everything else quickly, but this day may come.
What do you think?
Interesting Firefox for Android bug: Camera remains active when the app is in background or the phone is locked. That is, when the camera is on and streaming via WebRTC, if the user locks their phone, the camera continues streaming.
For a user to be affected by this they woul need to:
* They would need to visit a website using webrtc
* Grant Firefox the Android camera/microphone permissions
* They would then be prompted to allow the website access to the camera and microphone
* For this to be a persistent problem the user would need to check a box that says “Remember my decision for this site” this is unchecked by default in the above dialog
This, of course, what everyone does when trying to use a web video chat.
What surprises me more about the bug is that Android allows apps to record video when the phone is locked. I didn’t know that. As far as I know, iOS doesn’t allow this. More than that, an app can’t even use camera if it’s not the front-most app — the frame just freezes until the app is back (I suspect we’ll see this change in the future versions, given that iOS/iPadOS 14 add an indicator).
Safari 14 will support platform authenticators for Web Authentication API (also known as WebAuthn). Current versions of Safari already support WebAuthn for security keys, such as YubiKey, which are called roaming authenticators, but soon you will be able to authenticate using Touch or Face ID on supported devices without any external keys; this is called a platform authenticator.
This is already supported by Chrome on Macs, but the importance of the new development is that millions of iOS and iPadOS users will be able to use WebAuthn without dongles.
You probably know that salting is needed to make each password hash unique so that an attacker couldn’t crack multiple hashes at once.
This was already known to the Unix creators, according to the paper written by Robert Morris and Ken Thompson in 1979:
Password Authentication for Web and Mobile Apps is now available in Amazon Kindle Store. If you like the convenience of buying your ebooks there, go get a copy! Don’t forget to leave a review after reading it.
The book continues to be available from my website. In fact, you and I get better value if you buy it directly from me: in addition to the MOBI version for Kindle, you’ll also get an EPUB that you can read on any device and a nicely formatted PDF version. You can pay with a credit card, PayPal, or even with your Amazon account (in some countries). And I get a bigger cut of what you paid 🙂
Many apps with client-side encryption that use passwords derive both encryption and server authentication keys from them.
One such example is Bitwarden, a cross-platform password manager. It uses PBKDF2-HMAC-SHA-256 with 100,000 rounds to derive an encryption key from a user’s master password, and an additional 1-round PBKDF2 to derive a server authentication key from that key. Bitwarden additionally hashes the authentication key on the server with 100,000-iteration PBKDF2 “for a total of 200,001 iterations by default”. In this post I’ll show you that these additional iterations for the server-side hashing are useless if the database is leaked, and the actual strength of the hashing is only as good as the client-side PBKDF2 iterations plus an AES decryption and one HMAC. I will also show you how to fix this.
Devise is a popular authentication solution for Ruby on Rails. Most web apps need some kind of authentication system for user accounts and Devise allows adding one with just a few lines of code. This is great for security — if all the developers need to do is to plug a third-party library, there are fewer chances to make a mistake. This, however, requires that the library itself is implemented correctly, which is, unfortunately, not the case for many of them.