Jump to content
Phishing Emails & YouTube Messages - Fake Giveaway Read more... ×
Search In
  • More options...
Find results that contain...
Find results in...

colonel_mortis

Administrator
  • Content Count

    3,416
  • Joined

  • Last visited

Awards


About colonel_mortis

  • Title
    Keeper of the Private Keys

Contact Methods

Profile Information

  • Gender
    Male
  • Location
    UK, Center of the Observable Universe
  • Interests
    Programming
  • Biography
    ┌ I was born.

    ├ I found LinusTechTips.
    └ Now.
  • Occupation
    Developer, Moderator and Student

System

  • Display(s)
    Dell U2515H 1440p Monitor
  • Operating System
    Fedora

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. colonel_mortis

    Your 8 char random password now means nothing

    That wouldn't give any benefits. Over the wire (between your browser and the server, assuming you are logging into a website), the password is encyrypted using an encryption algorithm like AES-GCM. As part of that encryption, random data is added, so that next time you log in the encrypted version of the password is completely different (in fact, AES provides CPA security, which means that even if the attacker knows your password, they can't tell whether the encrypted message contains that password or not). This means that adding random nulls doesn't increase the security over the wire. In the database, the value stored is a one-way cryptographic hash of the password. This means that you can't decrypt the stored value to learn the password - the only way to check whether the entered password is correct is to hash it and see if the result matches. If nulls are inserted into the password at random, checking the password would mean hashing and comparing it with all combinations of null placements. This makes it much more computationally intensive to use, without adding much complexity for an attacker. If you're just interested in increasing the complexity, many hash algorithms have a configurable "difficulty" setting, which can be turned up for a more effective increase in difficulty. To make two hashes of "password" give different values, to make brute forcing more difficult, a salt is added to the hash, which is a random (but known and stored with the hash) value. This means that the attacker has to brute force separately for each salt value, which makes it much harder for them without adding much complexity for the user. Lots of clever people have spent a long time designing algorithms that are fast for legitimate users but hard for attackers. Trying to find neat tricks for making things more secure is a great way to learn about the design decisions that have been made, but they almost universally won't offer a security benefit.
  2. colonel_mortis

    Your 8 char random password now means nothing

    Indeed, that is very true. Dictionary attacks are far more effective than a pure brute force, so having a password that nobody else has ever used, and which you haven't used anywhere else, is by far the best defence. However, as the original article demonstrates, if it's stored as an NTLM hash, even a pure random 8 character password can be brute forced in a practical attack, so the only defence against that is to make your random password longer. A blank character is distinct from any other character ("password" is not the same as " password", "password ", "[NULL]password", or anything else like that*), so you can't have "no character" in the middle of a password. It's just the number of blanks that matter, not their position. *(assuming of course that a sensible hash function which distinguishes those cases is used, but I'm not aware of any password hashing schemes for which this is not the case)
  3. colonel_mortis

    Your 8 char random password now means nothing

    If the brute force algorithm just randomly chooses passwords from the space of permitted passwords, that's true, but that's not a useful assumption. If the password length is limited to 32 characters, the length of real passwords is not uniformly distributed across the space of permitted passwords. To a first degree approximation, shorter passwords are more common, and when combined with the fact that the search space goes up exponentially a random search doesn't make sense. Trying passwords from shortest to longest is still a brute force attack, but it is more likely to find a password earlier in the search. Under this search scheme, which I would argue is much more likely to be used by someone who really did want to brute force your password without a dictionary, a 9 character password is much more secure than an 8 character password (specifically, 26x if the password is known to be all lowercase letters, with the difference increasing as the alphabet does). Assuming an alphanumeric password, there are 628=218340105584896 different 8 character passwords, and 62+622+623+624+625+626+627+628 = 221919451578090 different passwords of up to 8 characters, which is 1.6% more. The difference of including shorter passwords is negligible (but it makes the maths less nice, so it's often omitted from back of the envelope calculations).
  4. colonel_mortis

    IntelliJ Auto Complete

    In the file list, is your file marked as just a java file (icon like a document) or as a java class (blue circle with C in)? If it's the former, you need to right click on the directory at the root of the class path (if your file is in src/com/linustechtips/Forum.java then it's the src sir, and if you don't have a package set then it's just the parent dir) and Mark As -> Java sources root.
  5. colonel_mortis

    Some older GPS devices may stop working in April

    According to the article, there is so I guess this is why it mostly affects older devices. My guess would be that when they designed it, there was no expectation that devices would use GPS for synchronising time (after all, it was designed purely for military use, and was only later opened to the public). Still, yes, it really feels like someone should have thought about and avoided it.
  6. colonel_mortis

    Your 8 char random password now means nothing

    Yeah, it's an often overlooked subtlety, though I have already halved those numbers (268/43551/86400 = 55.5 days to test all passwords, so an average cracking time assuming a completely random password of 27.25 days).
  7. colonel_mortis

    Your 8 char random password now means nothing

    The salt is assumed to be known to the attacker too, and is stored along with the hash in the database. The salt just exists to make Hcolonel_mortis(r00t) ≠ HTeddy07(r00t), so the attacker has to brute force each user (or technically each salt, but the salt should be sufficiently random that no two users have the same salt) separately. In the standard format for storing hashes, the hash algorithm is actually encoded with the hash, so that even if the hash algorithm used for new passwords has been changed, you can easily know which hash function to use to check the password. The hash function is assumed to be public knowledge - the only thing that protects the password is the fact that actually computing the hash function, to brute force the password, is intentionally very computationally hard. If it takes 10,000 years to try all of the hash combinations for one salt, there's no way to precompute a table of hashes for all salts either (and to make the hashes practical to store, you need to use a datastructure like a Rainbow Table, which requires lots more uses of the hash function, making it even less possible). However, assuming they don't know the hash function, they can be pretty sure that they have found the correct hash function as soon as they find one that produces a matching output - the probability of any given hash function producing a given output for a given input is 2-128, or 0.000000000000000000000000000000000000003%.
  8. colonel_mortis

    Discord Ban?

    Can you PM me your discord username and discriminator? This is best handled through PM, so I'm locking this topic.
  9. colonel_mortis

    Your 8 char random password now means nothing

    It is always assumed that the attacker knows the hash function. It wouldn't be hard to find out what hash function it is - if your own password is included in the dump, just hash your password under a bunch of hash functions until you get a match. For the specific hash function discussed here, NTLM (the Windows password hash algorithm), there is no salt. This means that the attacker doesn't have to target any specific user - they just calculate the hash of each 8 character password, and see whether any users match that. For a more secure hash function, such as blowfish (used by LTT), each password has a unique salt added, which means the attacker has to brute force the password for each user individually. If two users have the same password, the hashes will be different because the salts were different. If that were the case for NTLM, it would take 2.5 hours per user. For blowfish, the time taken to brute force every 8 upper/lower/numeric character password is measured in millennia, and that is per hash to be cracked. In theory, and in practice for the hash functions that are used for passwords, the attacker learns nothing about hash(A) by computing hash(B), for any A ≠ B. This means that they have no choice but to brute force if they want to crack the hash.
  10. colonel_mortis

    Samsung UNPACKED Event Feb. 20, 2019

    It still doesn't meet the Tech News posting guidelines - Moved to General Discussion
  11. colonel_mortis

    Your 8 char random password now means nothing

    Blowfish is a very popular (and still considered strong) password hashing algorithm, so it's fairly likely that some VPN providers will use it for storing your password. The hash algorithm only protects against someone accessing accounts after compromising the database - the actual data transferred will be encrypted using a symmetric cipher, almost certainly AES. Yeah, I ran that on my low power laptop. The point is how much slower Blowfish is than NTLM. Even at 43551 H/s, it would take >25 days to brute force an 8 character entirely lower case password, and >3 million years 2.5 millenia to brute force an 8 character mixed upper/lower/numeric password.
  12. colonel_mortis

    Your 8 char random password now means nothing

    (Moved back to Tech News) It's worth noting that this is specifically NTLM hashes, which means Windows passwords. Most websites will store your password using an algorithm like Blowfish, Argon2, or at least PBKDF2, which are all designed to resist brute force as much as possible. On my laptop (i7 6500U, integrated graphics) I get 235,000,000 H/s for NTLM, but only 131 H/s on Blowfish. Your Windows password can be brute forced if someone obtains access to the password store file, but your LTT (blowfish) password is much more secure.
  13. colonel_mortis

    Some older GPS devices may stop working in April

    My assumption is that they will keep using the most up to date model (which is regularly updated and transmitted from the satellites and from the internet/terrestrial radio), but extrapolate it to the wrong place (1999 rather than 2019). It will then still be able to get a GPS fix, but it will be in completely the wrong place. I'm not saying you should sell your old GPS devices, and the chances are that most were designed with this in mind (and those that weren't are probably too old to be worth anything). However, if they do break in April, this might be why.
  14. colonel_mortis

    Some older GPS devices may stop working in April

    For calculating location relative to the satellites, all that matters is the difference between the times, so it won't matter. However, you also need to know the locations of the satellites to be able to get a fix, and they are moving fast. To get the positions of the satellites, they broadcast a precisely known position at some point, and a model for how the satellite is moving, to allow the receiver to calculate the current position. If the GPS receiver thinks that the current year is 1999, it might try to extrapolate the model back 20 years, or it might just break. There's also a bunch of services that use GPS for precisely calibrating clocks, which could be thrown off by this.
  15. Source: https://www.theregister.co.uk/2019/02/12/current_gps_epoch_ends/ More recent GPS devices (The Register says ~2010+) that follow the specification will be fine, since the specification requires graceful handling of the overflow. However, some older or less well engineered devices might not support it correctly, which would result in them calculating the current time incorrectly as being in 1999 rather than 2019. This in turn may result in them breaking or calculating the location incorrectly, because they will calculate the position of the satellites incorrectly. GPS is used for more than just location - it's effectively just a very accurate broadcast clock, which is used by some datacenters (among other things) to get the precise time. If these devices aren't overflow-tolerant, it could cause a range of issues for services hosted in those datacenters, which often rely on the assumption that time monotonically increases. This is unlikely to have any widespread or severe effects, and the vast majority of devices, including all safety-critical ones, should be fine. There will inevitably be some issues caused by rushed software by some vendors though, which could break a few less important things.
×