Binary safe, Memory Usage, WeChat, WebAuthn, Hosting

  1. Programmers thinking they can hide something in the code. Lulz, today I again hacked one application doing the classic fail. No, you can't hide stuff in binary. Because when it runs, at some time the data will be in the system memory accessible and it can be copied and dumped out. So much fail. Yet this is extremely common misunderstanding with developers. And I have to confess, I've done the same. Over and over again. But why? Mostly because some customers require that data must be "encrypted", which often means slightly obfuscated, so it isn't immediately obvious what the content is. - Now someone claims that you should use proper encryption. Honest question is, what would that help? If the attacker is able to deal with the obfuscation, they're also able to deal with the proper encryption using similar means. They do have access to the encryption key, as well as the data being decrypted, and final decrypted plaintext. Doing proper encryption would basically be waste of time. Yet often I do provide easy way to change the "encrypton key". Yet it's still mostly pointless. It's only protection from the most incompetent attackers without time, interest, resources and competence to deal with the situation. Sure I could use sha512 and aes256, but that wouldn't change the end result in any meaningful way. No, I'm not talking about end user password, but storing API keys and such stuff sensitive information.

  2. Discussion about process memory consumption. I personally do like - online algorithms - https://en.wikipedia.org/wiki/Online_algorithm - and programs which allow processing data in small chunks, without knowing about past or future.

  3. We Chat, They Watch - Excellent article with well explained backgrounds. Using hash index for immediate blocking is very expected approach. Some apps even do that using the customers end devices, I've read. Dynamically updated censorship, isn't that the only way of it makes any sense anyway.

  4. In a way this article is great sample, why communications should be encrypted and protected. Censoring private communications is kind of twisted stuff. but nothing new. It's good to notice, when they say "non real time" censorship, it still means that it's probably in seconds when the content is censored. So it's fully automated process. I might have been also interested to see, if there are steps which take more or less than one minute. Like 15 seconds and or let's say two days later, when there's a possibility for human intervention as well. The collision side-channel test was particularly interesting. Loved the privacy policy analysis, as well as the fact that why, when and with which parties the data is shared was left ambiguous. As well as how much of it leaks to Chinese authorities for profiling and analysis. But many seem to forget that also western companies often have censorship policies in place. Long but excellent article. kw: WeChat, China, Communication Security, Censorship.17

  5. Helped a friend to setup WebAuthn / U2F / 2FA / MFA / 2SV with alternate TOTP verification for the web-site as well as I were in the early beta tester group. Based on the initial implementation, I added a few extra requests. 1) Option to use a recovery code in case 2FA secrets are lost. 2) Option to register more than one FIDO2 token. Then it's good. 3) A few changes with the login process, now it was slightly confusing. Setup was bit too quick, without any instructions and usage required a few extra clicks to let the site to know, if I want to use WebAuthn or TOTP and then extra step to activating the U2F token or entering TOTP code. Let's see if the process can be streamlined and improved. Afaik, the usage when logging in, should be as straight forward as possible. But during the setup, it might be a good idea to give little instructions to the user. As example, letting them know, that if there's only one token registered, there's no way to recover the account without the token etc. 4) I was also slightly confusing that that disabling U2F required account password, but disabling TOTP required TOTP code. - No, I don't exactly know what to think about and what's the best solution in current situation. If you've got only TOTP or U2F enabled, then you can't login without the token anyway, so... Anyway, it's good to verify the disabling of MFA features, so that someone can't simply click it when you're logged in and later abuse the account.

  6. Long discussion about on-prem, co-located, and cloud servers. Depends from the project and technologies used which one makes sense. There's no simple answer to these questions. But for sure, cloud does make sense in many cases.

2021-05-23