• 0 Posts
  • 28 Comments
Joined 6 months ago
cake
Cake day: May 20th, 2024

help-circle

  • One example for self documenting code is typing. If you use a language which enforces (or at least allows, as in Python 3.8+) strong typing and you use types pro actively, this is better than documentation, because it can be read and worked with by the compiler or interpreter. In contrast to documenting types, the compiler (or interpreter) will enforce that code meaning and type specification will not diverge. This includes explicitly marking parameters/arguments and return types as optional if they are.

    I think no reasonable software developer should work without enforced type safety unless working with pure assembler languages. Any (higher) language which does not allow enforcing strong typing is terrible.


  • I have worked on larger older projects. The more comments you have, the larger the chance that code and comment diverge. Often, code is being changed/adapted/fixed, but the comments are not. If you read the comments then, your understanding of what the code does or should do gets wrong, leading you on a wrong path. This is why I prefer to have rather less comments. Most of the code is self a explanatory, if you properly name your variables, functions and whatever else you are working with.






  • A bit of both. The Allies started denazification. Then the western allies and Germans who got into power (including Nazis) became less and less strict as they realized they needed some of them to build up structures of society, especially with the cold war beginning. And of course Nazis protecting Nazis.

    The allies even gave some groups of Nazis weapons to prepare for a guerilla war in case Stalin invaded West Germany (see Gladio and other stay behind groups).

    Not punishing Nazis for their crimes was so common that there is a word created for this specific meaning: A Nazi or collaborator basically getting pardoned or even getting the authorities formally void their offenses/atrocities: Persilschein. The word refers to a popular brand of laundry detergent, similar to the phrase"whitewashing".









  • If it is just the location, then it could be spoofed.

    If it is something that requires physical presence, then you need both devices to communicate with each other. If it is not done via QR code (like some online banking do), then both devices need to be connected, e.g. via WiFi or Bluetooth. In this case, if an attacker controls one of the devices (that’s the class of attacks 2FA should prevent you from), the attacker probably controls both devices. So what’s the point then?



  • How would MS Authenticator make it any better than TOTP?

    To break TOTP, the attacker would need to:

    a) be able to observe the initial exchange of the TOTP secrets. To do that, the attacker needs access to the victim’s computer (on user level) at that specific time they set up TOTP. TOTP is a TOFU concept and thus not designed to protect against that. However, if the attacker controls the victim’s computer at that time, the victim is screwed anyways even before setting up 2FA.

    b) have access to the TOTP app’s secret storage and to the victim’s login credentials (e.g. by phishing). If the attacker can gain that level of access, they would also have access to the Microsoft Authenticator’s secret storage, so there is no benefit of the Microsoft app.

    On the other hand, Microsoft Authenticator is a very huge app (>100MB is huge for an authenticator app, Aegis is just 6MB, FreeOTP+ 11MB), i.e. it brings a large attack surface, especially by connecting to the internet.

    I don’t think Microsoft Authenticator brings security benefits over a clean and simple TOTP implementation.