deadcade @ deadcade @lemmy.deadca.de

Posts

0

Comments

179

Joined

2 yr. ago

The times I calculated were indeed going over every possible combination, it would take half as long to crack a password on average. Considering reducing the time to 1/1000000 still leaves you with an incomprehensibly large estimated timespan, dividing that by 2 doesn't do that much for making it brute-forceable.

I did note it was specifically for 8 emojis, not 8 characters or bytes.

And yes, it's very impractical and likely to break things. It's better and much easier to add extra letters, numbers, and symbols to your password rather than using emojis. Using a password manager is even better.

As you stated, a single unicode character would mean your password wouldn't be included with the potential options in almost all brute forcing tools. Whether you use 8 emojis or 1, your password likely won't get brute forced.

All of my "emoji password" numbers are if the attacker knows it's a password containing exactly 8 emojis, and nothing more. Adding a regular symbols+upper+lower+numbers 16 character password would make it even more impossible to brute force.

For somewhat more realistic numbers:

According to minerstat.com, an NVidia RTX 4090 has a hashrate of 118.07MH/s. This is 118.07 Megahashes per second, or 118.070.000 hashes per second. For a password with only 8 lowercase letters (208.827.064.576 combinations), it would take an RTX 4090 approximately 1769 seconds (or ~30 minutes) to go through all possible combinations. For an 8 character upper+lower+numbers password (218340105584896 combinations) it would take 1849243 seconds, or 21.4 days.

For an 8 emoji password (32482071647592311234920185856 combinations), it would take 275.108.593.610.504.896.512 seconds, or 8.723.636.276.335 years.

Lets say a magic prediction algorithm reduces the number of possible combinations in each password to 1 out of every 1 million previously possible combinations. 8 lowercase letters would be cracked instantly, while an 8 emoji password would still take 8.723.636 years.

NordPass is completely incorrect on the "it makes a password easier to "crack" thing.

I absolutely don't recommend using emojis in your password, as it is far too easy to get locked out. However, a password containing an emoji is significantly harder to crack.

Hashing is a process used to calculate a large number based on some input data. If the input is the same, the output is the same. If the input differs just slightly, the output is completely different. This process is mathematically irreversible. Since this (and other techniques) is often used for passwords, to "crack"/bruteforce a password, the attacker has to go through every possible combination of input data, calculate the hash, and check if the hash is the same as the password hash.

To make the process of bruteforcing a hash quicker, an attacker often makes assumptions about the input data. If they know a password contains 8 characters, and only lowercase letters, this massively narrows down the amount of passwords that need to be hashed and checked. If they know the password contains someones birth year, that too reduces the time to bruteforce a password.

The more possible characters you have per position in your password, the longer it will take to bruteforce. An 8 character password with just lowercase letters has 208.827.064.576 possible combinations. This sounds like a lot, but it's often bruteforced rather quickly. Adding uppercase letters and numbers to that, we're already at 218.340.105.584.896 possible combinations. That's ~1000x more combinations, and that's for 8 characters. It's the difference between bruteforcing taking a day, and taking 1000 days. (Do note an 8 characters lowercase password probably only takes like a few seconds to minutes, not a full day.)

According to https://emojipedia.org/stats there are 3664 different emojis. Lets say we create an 8 emoji password. (some emojis aren't one character internally, the same principle still applies.) Just 8 completely randomly chosen emojis. That password would have 32.482.071.647.592.311.234.920.185.856 different possible combinations. That is about 148.768.232.755.857 times more combinations than an 8 character uppercase+lowercase+numbers password. That is the difference between bruteforcing taking a day or taking 407584199331 years.

The same things as non-emoji passwords still apply, you can make assumptions about which emojis are used. People aren't entirely random, so chances are higher they used some of the more common emojis. However, that is similar to prioritizing the letter "e" because it is more common. Yes, it'll probably reduce the time taken to bruteforce a bunch of passwords, but it's not set in stone that every password will even contain the letter "e".

Again, due to the potential of breaking things, locking yourself out, etc. I DO NOT recommend using emojis. Use a password manager with longer passwords.

However, including an emoji in your password makes it significantly more difficult to bruteforce. As the assumption that the characters in your password are letters, numbers, and symbols no longer holds, which drastically increases the possible number of combinations.

You want a magic Discord speedboost? It's called OpenAsar. Mitigates telemetry, and speeds the client up to usable levels, especially on lower end hardware.

Although with most games, the accessibility options need to be there (even when they sometimes aren't), some games incorporate their movement mechanics into gameplay heavily. Take BONELAB for example. Great game, but simply impossible to play for some people due to the movement. Adding teleporting (or really any accessibility movement option) would simply ruin it though, as the entire game is based around physics based interactions, walking, running, jumping, climbing, etc.

Currently on Phosh on postamarketOS. Would've loved to use Plasma mobile but it is very unstable.

As if iMessage, the platform that requires hardware from a specific company, is much better.

Although Unity and Epic are not related (other than both being companies that make a game engine), and Epic is not related to these Unity pricing changes, Epic has still done a lot of things "wrong". Especially for gaming on Linux. A lot of games that are currently unplayable under Linux is due to kernel-level (rootkit) anti-cheats. Being the creators of EAC, Epic has actively been harming the compatibility of games on Linux. Developers "can enable Proton support", but even Epic themselves in many of their own titles don't enable this.

They haven't pissed off the larger gaming industry to the point where everybody is moving off their platform/products, but they are still a greedy corporation. Remember the whole exclusives thing on the epic games store?

I can personally vouch for how toxic the Discord server and its moderators/admins are. Went there for support (Hyprland was crashing on startup on AMD, sway worked fine), and was told something along the lines of "if you can't figure this out you're stupid and you should stop using Linux". Figured out the issue on my own and stopped using and recommending Hyprland after that.

Crackers often only patch out the DRM to redistribute a pirated copy of a game. If it is a game from a small studio, something like Goldberg is enough to "crack" the game, and it wouldn't remove any of the Unity telemetry.

Ah yes, because it's that difficult to spoof a new PC. You can run a tool similar to a kernel level anti cheat "ban bypass", run the game, and cost the developer up to 20 cents. With a relatively simple script, this can be done many times per hour on a single PC, easily racking up cost for the developers.

This is a bad idea, no matter how you implement it. If it goes through, it will be abused.

WireMin, as far as I can tell, is not open source. There's no way to prove that any of their claims are actually true. Plenty of messaging apps have claimed to be "decentralized" and "end to end encrypted", but those have been false claims a lot of the time.

I would suggest you look into Matrix and XMPP, which are actually decentralized protocols rather than a single closed source app. Since they're open protocols, there's actual proof of them being decentralized and end-to-end-encrypted.

Reading through the WireMin privacy policy and ToS, they are making several impossible claims, such as:

"No user information will be provided to us, not a single bit."

As a somewhat tech-savy Matrix user, I can already tell you there's literally no way for them to not receive user information, simply by having an app on the app or play store, user information gets sent to them for each download. Many functions in the app also cannot work without a publicly accessible server. Things like notifications, or even receiving any messages at all while the client device is behind NAT.

They even back down on their own statements in that same privacy policy:

"WireMin collects minimum device information, such as version number, platform, etc."

And they clearly say a push notification token is obtained, which requires server infrastructure to use:

"Occasionally for WireMin App on mobile devices, an additional device notification token (e.g. iOS devices) may be collected, to enable push notifications. Again, that information is collected without exposing user identity or the device's IP which eliminates the possibility of user tracking."

While also claiming it is collected "without exposing user identity or the device's IP", which is impossible to do. (iirc) The IP protocol requires source and destination IP addresses to be known on both sides (even if I'm misremembering and it's not the IP protocol, TCP still does).

Although I have not dug through the app, to figure out how it works internally, I can assure you it is not "decentralized", and will go down or at the very least lack basic features as soon as their servers are shut off. Them lying about such a "large" aspect of their platform also makes me heavily question the "E2EE" claim.

Platforms such as Matrix or XMPP solve most of the issues I noted here by having decentralized servers, but ""centralized"" clients (clients only connect to one server). If any one server goes down, the clients under that server are affected, but the rest of the servers (and thus the rest of the network) is not affected.

Not just the "lack of APKs", but the lack of a FOSS build. As you noted, it is possible to instal an AAB by extracting the APK(s) inside, but that doesn't magically remove non-foss libraries.

The only build is an aab file. This is a Play Store bundle file, not an APK, so not directly installable in Android without the Google Play Store.

The only build being a Google Play release also indicates that non-foss libraries were likely included, such as the FCM libraries, as is common for GPlay releases of otherwise FOSS projects.

As far as I'm concerned, Element X for Android is not available yet, unless either building from source (with modifications to included libraries), or by using a non-FOSS version from GPlay.

Your iPhone 13 syncs slower over USB because Apple decided to stay on Lightning connectors, which use USB 2.0 on the other end. Although FireWire was faster back when it co-existed with USB, the USB standard has surpassed it a long time ago with more power, faster speeds, and better physical connectors.

The source code for a decompilation of a game can only be available legally because someone who isn't the original dev created the decomp and decided to share it publicly. All assets in the game were still created by the original developers, and can't be freely shared. This means the open source decompilation will need a way to load assets from the original game to remain legal to redistribute. This includes things like textures, 3d models, and music.

Chances are, once this project is completed, you'll need an original copy of the game to play, and it'll use the cars, maps, and music from the original game.

"Android" phones can sometimes have "close to mainline" Linux distributions flashed onto them. You can get some of those, used, for less than 100$.

A custom Android rom would provide you with a decent chunk of the freedom you want in a mobile device.

A phone specifically built for Linux, with as much as possible FLOSS firmware, will cost a lot more. The cheapest is probably the PinePhone.

For a distribution like Fedora, it's usually not required to turn off secure boot. You'll know if it's needed when booting the install USB, as it'll give a "security policy" (or similar) warning.

Other things of note when dual booting are Windows "Fast Boot" and "Hibernation" features, which can put hardware in a state where it is unusable from Linux. Turning those off in Windows can fix things like your network interface not working. Windows also stores the time in a different way than Linux, if you are in a non-utc timezone, setting up NTP (automatically syncing date and time) on both Windows and Linux can help.

The native client has application level access to the rest of your machine. They use this to run process loggers "for the activity display", or the button that allows you to quickly stream a game if it's running. They could theoretically use this access for keylogging or accessing the mic without explicit user permission. Running the Discord web client keeps the source of collected telemetry within the webbrowser, which doesn't offer keylogging or process logger features, and requires explicit user permission to give websites access to a microphone, camera, or the screen for streaming.

Yes, they do process log on the native client, and from my own GDPR data request it appears they keep this data in detail for a couple of years: https://github.com/snapcrafters/discord/issues/43

The source code of a program is like a recipe and list of ingredients. If you buy a coffee from Starbucks, you get a coffee from Starbucks. You can't easily change the beans used, the brew temperature, etc. With the recipe, you could brew your own with slight differences, or make coffee from scratch knowing everything that's in Starbucks coffee. With the source code for a game, you could change/mod anything. FPS unlock mods, ports to other platforms, and much more. You could make your own game, and make it better knowing how some systems work in another game.

Some games have their source code leaked, in which case it is illegal to own, redistribute, or learn from the code. Although it'll usually still happen, it's much more "underground" than games where the source code was reverse engineered. Reverse engineering is like buying a coffee, tasting it, then coming up with your own recipe. Having your own recipe almost exactly identical to the original still allows you to make changes easily, but it's not illegal, as you wrote it, and are allowed to share your own recipe. Some older titles like Super Mario 64 have been fully reverse engineered, and ported to every possible platform, with multiplayer mods, FPS unlock mods, etc.