akaiser

Eludes me why they didn't have device-certificate-based auth for their Enterprise WiFi in addition to the username+password. Basically comes for free with AD and NPS.

A wallet app like Exodus is not for keeping BTC, it's for transacting with it.

The wallet file is for keeping BTC, and whether you print it on laminated paper or copy it to multiple USB sticks that you distribute in multiple places (you can encrypt a USB stick, but not really a piece of paper, so beware who has access to your storage!), doesn't matter once you want to use your BTC. Using your BTC requires a computer and a wallet app; there's no way around that besides online platforms.

The real solution for fake wallets is to independently validate signatures of wallet app releases or to build from source yourself. Also wait for a few weeks before jumping onto the latest wallet version. Who knows if the developer's supply chain got compromised.

Edit for completeness: Last but not least, do offline transactions (send the signed transaction using an online device without access to the wallet).

Then again, an attacker can read the decryption key from RAM (freeze and remove the modules, then dump the memory on another system) and decrypt the disk offline.

So, data on a stolen laptop which has an unprotected TPM (no PIN to boot) can be considered compromised.

Technically there is no requirement for a mobile app or data. Through PayByPhone you can pay for parking using SMS, by calling (IVR), a web app or mobile apps. But as the author points out, it's hard for the user to know about all the options. That's why I'm personally not a fan of cities that allow more than one vendor. How to advertise all of them on sign posts and stickers (sometimes given different location IDs that you need to use with each vendor) without overwhelming the user?

Note: I work at PBP

The article describes the fact that the CM Browser ignores certificate errors and shows websites as though they were properly secured. Having an actual proper setup (with a trusted CA etc.) wouldn't help here, because a MITM attack would not be visible, because the middle man's certificate would be shown as valid in any case.

I assume Tencent's QQ Browser validates certificates properly, but combined with a horrible RSA implementation that's not worth anything. It's actually a more clever (less visible) way of pretending to establish secure/authenticated connections.

The final goal this probably had is already achieved (a lot better) by properly configured TLS. I think this only prevents having the password in clear text at some specific point in time on the servers and (accidential) logging. OK, maybe some active MITM software (hi Lenovo!) that have not specifically been adjusted to replace the JS crypto may have been a concern. But probably someone just wanted to play around with JS crypto ;-)

They could have made this easier and faster by simply having the client apply a hash (have the server provide a temporary salt and mix it with a client-generated salt if you want to prevent accidential logging on your server) and handle this result as if it was the user's password (and hence hash this hash properly server-side). As already noted, the (only) upside is that now you don't ever even process a user's password on your server, so you don't have to worry that a user's password might be stored in your logs or even MITMled in your own (unsecured) network. I wonder why I have never read about somebody handling logins this "double-hashing" way? Anything I'm overlooking security-wise?

You should have started with the NCHAR(2000) example. Choosing INT over BIGINT is really something that, as you calculated yourself, wouldn't change the fate of a project. Especially not in our 64 bit world ;)

The point you make about timestamps is very clear to everybody. Do you have more examples which people don't think about?

Thanks for pointing to your low-latency-switching strategies, was an interesting read! Although I see how it is great for a high availability strategy as a side-effect, I wonder why you did not want to make use of location information on the phone. I mean having the user send his coordinates with his first request would be the obvious choice, but privacy considerations could speak against it. But if your returned list of available servers for a region would include coordinates, the app would not have to establish connections to all the servers, but maybe just the closest X. That could improve the whole process and save a tiny bit of traffic if you had a lot of servers in every region. And what about having a list of all your available servers cached with their coordinates in an encrypted sqlite database then? Firewalls that filter the single domain that is queried for server information would not be as successful. On the other hand, old or compromised servers would have to get revoked regularily. Or Have you had more problems with the idea of phone locations and local server lists?

Let's wait for someone to find a vulnerability based on that bug then. Ideas, anyone?