Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)CR
Posts
1
Comments
333
Joined
2 yr. ago

  • Because there are laws that specify when the brake light has to come on, and it isn't when the car shows down (slightly). You could be starting to go up hill, or a list of other reasons. The point of brake lights isn't too signify the car slowing, but that the driver intends to slow down. Which is also why it doesn't come on if you're motor breaking" (is that the right term?).

    This obviously varies wildly depending on where you are in the world. I'm also sure there are some places where it would be allowed.

  • As far as I'm aware, the aegis database format is only used by them. You also can't do an automatic import (only export), so keeping multiple systems in sync (particularly more than 2) can only be tedious.

    If that's what you're after, just use a KeePass database, in particular if you're already using one anyway. Most clients can sync with a remote storage (like Keepass2Android or KeePassXC on multiple platforms), and I do mean real sync: Both sides can have modifications, and it'll consolidate them correctly (of course unless both have modified the same entry, then you'll be prompted). Just throw the database onto a nextcloud or something, as the clients can also usually talk to that directly without another app doing the file transfer (at least Keepass2Android can).

    BitWarden has a pretty good reputation, and is a frequent recommendation as well. But then again, so was Authy... With your own VaultWarden as the backend (if you can easily host that yourself) it would be a no brainer as a near universal solution. And this would probably also be "secure enough" for normal, everyday purposes. It can import and export a KeePass database btw, if that helps.

    Since I haven't actually said anything about how I'm handling this, here's a quick summary: Critical accounts use a complex password (stored in my password manager) and the 2FA is only stored in Aegis. There are generally backup codes on paper stored "somwhere safe", if this is supported by the service (google does, steam does, ...). On any account that just happens to require 2FA, but I don't use it for anything critical, the TOTP is just stored inside my password manager, for convenient auto-filling. Examples are a Twitch account (I don't stream, I just happen to have an account for chat and stuff). My password manager is also KeePass-based and used on multiple systems, sync'd via nextcloud and with a mf'er of a password (plus an additional factor). I generally don't reuse passwords anymore, at all, ever: They are generated, at least 24 characters long (usually longer) unless the service prohibits passwords of that length (yes, this happens, surprisignly often actually). The password database is of course backed up in like 3+ different locations, and some are located somewhere physically different (i.e. not at home).

  • For it to do that, "Auto-Correct" in the Gboard settings has to be on. You can also kind of accidentally kill a feature like this by having a single lowercase i added to the dictionary. If you have, just remove it like someone showed above. Note: there is no list of words in the options anywhere where you can see the list, you can do it while typing anywhere though. Just type a single I, press space, then backspace, then drag the single "i" entry from the suggestions to the trash that appears when you hold the i.

    side note: I have typed this comment using Gboard glide, and I had to correct a total of 2 words. Everything else was recognized as intended.

  • Basically any game that doesn't in itself follow a story, so you are the story (or make it). For me personally it's building and factory games, like Factorio, cities skylines (1 or 2), satisfactory, Kerbal Space program (1 only), Rim world.

    This list is essentially endless.

  • Well to be frank, the fact that you're asking this shows you haven't really understood what makes something secure or insecure, or it isn't as important to you as you claim. If you want your stuff to be secure, your phone is the only "thing" that generates the 2nd factor. Especially things that are critical shouldn't have duplicate devices being able to also generate codes. If you do want to generate codes for less critical accounts somewhere else, you should register a 2nd TOTP generator with that service and use one each per other machine. That way, if something gets compromised, you can just revoke those devices preventing any damage without having to re-setup existing 2fa again for the devices that weren't compromised.

    Now aegis is Android only, like you said. It also has no way of syncing with another instance (by design). It's local only, it can just do backups. Having it send the highly critical information anywhere kind of defeats the security-purpose of it being local only. It adds a whole communications protocol that has to be secured, and somehow you have to authenticate the other side and so on. This also probably doubles the complexity (or at least size of the codebase) for the project, which then makes audits harder et cetera. Aegis currently does one thing (generate TOTP codes), and does this very well and as secure as it can without compromises.

    Now for an actual answer: Most password-managers can also generate TOTP codes, like KeePass or KeePassXC to name two open source ones. But it's their secondary purpose, with the primary obviously being storing the passwords. I'm not going to get into the implications of storing a TOTP code generator secret together with the password of the account it protects, let's just say there are some. Since the actual secrets are stored in a (secured) database, you can sync these between devices. Or you can just create multiple TOTP generators for a single service and keep them separate.

    Or we circle back to something server based, like BitWarden, which is primarily a password manager but also does TOTP. It's a commercial, server based solution that is free for individuals. I'm not sure what the current limitations are for those accounts, like number of entries or just who you can share stuff with and so on. There is a open source implementation of their protocol called VaultWarden, where you can self-host the back end and not rely on the company securing their servers properly (and/or not being collateral damage in a breach of some kind). Again, combining password + TOTP-storage in the same service that is accessible online should be done with considerable thought to how it's secured, but you could use this to only store the 2fa aspect as well.

  • 2a. No 2fa, so this is a reduction in my current security

    That's open to interpretation. Your current solution you thought was secure, but you used a service that as it turned out had bad security practices, which you just didn't know (arguably couldn't know). ANY online/cloud service that you don't host yourself has this issue with being a black box of unkown quality. Any online service you do host has to be secured by you (or you need to trust that the base setup of that tool is "sufficiently secure"), and is in essence limited by your knowledge of the tool and technology used. Also if you're reusing any passwords, anywhere, just stopping that practice is likely more secure in practice compared to 2fa in isolation.

    2fa in general isn't just plaing "better" than not having it, security is rarely this black and white. It also depends on what is allowed to be the "second factor", and since yours included SMS, it really wasn't secure at all (like others have also mentioned in this thread). And it depends on the password of course. For example if you use a really secure password (30+ characters), and don't reuse it, it will in practice be more secure than a short(ish) password and a 2nd factor that allows SMS. Generally 2 factor is used as a term for 2 categorically different athentication methods: one thing you know (password, pin) and one thing you own (phone, physical device/key, or a file works too). The problem is that SMS doesn't require your phone. It's incredibly easy to get the SMS without having your phone (even easier with physical proximity) or flat out faking owning your phone number (dpends on a lot of factors how easy or hard that is in practice, doesn't require physical proximity). Basically, if someone actively targets you and/or that account secured by SMS 2fa, it isn't overly hard, but it's good enough at preventing giving access through a data leak for example.

    So, back to the security of "solution 2a": how would someone get access to a long password you don't use anywhere else, that isn't written down anywhere (or nowhere accessible), and where you essentially never need to use/access the account in the first place? Nobody would even know that whole account exists unless you specifically tell them, let alone knowing how to get in. Note that this can also be combined with the concept in solution 4, so you're then using it to only restore a single 2fa code. So that "safety net fallback account" very rarely needs to be updated with a newer Aegis-Backup, making it even more obscure/unknown. That 2fa code then lets you access your normal account and backups, and you restore the full suite of 2fa you need.

    It boils down to this: local 2fa with a backup means you need to get access to a single file to securely restore full access to everything. That file can be transmitted insecurely (due to strong cryptography and hopefully a good password not used anywhere else), but I wouldn't store it out in the open either. On the other hand, any cloud based solution is an inherent black box. You trust them to properly do things, and you only know they didn't once it's too late (like Authy). It also means they are, by nature of what they do (storing account access information), a target and if the attacker is successful, you're the collateral without having been explicitly targeted. Maybe there are sevices out there that let third parties audit their security and publish the results, but I don't know of any and it would probably increase the price by an prohibitive amount for most people.

  • Well I thought this was kinda obvious what I meant, but I guess not. What you say is a requirement (sms recovery of a cloud account) is just one of many solutions to your specific problem. I'll just list off a few solutions below that involve neither SMS (the most insecure communication method in common use today) and only optionally a cloud account. For cimplicity sake I'll stick to Aegis, where you can create password-protected local backups you can then put wherever you want. This password needs to be very strong for obvious reasons: I would recommend a long sentence (40 characters or more) that you can just remember, like a quote from a movie/tv show/book/poem or something, including normal punctuation as a sentence for example.

    Solution 0: This is more of a trivial solution I wouldn't actually recommend. You can allow account recovery via eMail and have your eMail not use 2fa, but a long/good password so you can login from memory (see above). This is probably more secure than SMS for the recovery-case, but less secure for the everyday use case of eMail, therefore "not recommended".

    Solution 1: USB Sticks are tiny, as in the size of a USB port (slightly longer but slimmer for USB-C). If you want to have a backup "on you", I'm sure you can find a place where it wouldn't get robbed with the phone/wallet. A tiny pocket somewhere, a string around your ankle, make a compartment in your shoe, or just have it with your luggage at the hotel. I'm sure you get the point. You get your new phone, you plug in the USB, you install Aegis and restore the backup.

    Solution 2a: Dedicated "online" storage. This can be self hosted, or a free account of any cloud provider, but the important part is that it does NOT require 2FA and you do NOT use it for anything else. You have the backup in there. It also needs a very secure password (again: long, but easy to remember, no garbled letter nonsense), but obviously not the same as the Aegis-Backup. So you now need to remember 2 long passwords. You get your new phone, you log in, get the backup and proceed as usual.

    Solution 2b: If not having 2FA is not an option for the solution above, you can have a friend/family store the 2FA on his phone. To log in, you go to the login page and enter your password (which your friend doesn't need to know), and you ask him over the phone for the current 2FA-Code, which he tells you and you can log in, download the backup and proceed as above. I assume such a high security isn't that critical, since you have been using something involving SMS. Restore then goes as per usual.

    Solution 3: Store the whole backup with a friend and when you need it he just temporarily puts it somwhere you can access, and removes it again after. Since the backup is protected by a monster of a password, and the accessibility is temporary anyway, this isn't security critical.

    Solution 4: If you absolutely must, you can find a cloud-provider for 2FA, and use it only as the "first stage". The only 2FA code in there is the one you need to get access to your main online storage/account where you then have your real Aegis-Backup and/or other files. Obviously this service would need to allow you to login without 2FA, and the usual password rules resulting fom that apply. You can just add the 2FA of your primary service to more than 1 app or service, or if it allows for this, you can generate multiple authenticators so you can also revoke them serperately if needed.

  • The point is you physically and locally back up the database. Put it on your computer, or a flash drive or whatever. You can set a different, longer password for backups, and I would recommend you do that. When you get your new phone, you just copy the database into it and load it into a freshly installed Aegis. You don't even need to self host anything, there is nothing to host.

    Not everything needs to be "in the cloud". I think this event illustrates nicely why.

  • Yeah I was just so confused when I found out that this isn't possible. Like, it's a file hosting and sync-ing application. That's like absolute basics. It isn't even "just" an open source project any more, there's a company behind this product now. I am the last person to be angry about an open source project, run by a volunteer or three, not being feature complete.

    For what it's worth I think it works in the iOS version of the app (possibly always has?). But that's doesn't exactly help me either.

  • The native Android client just can't do two way sync. Just put a text file or something into any folder (from the web or desktop). Now sync that folder to Android. Now edit it on the web/desktop, and look for the changes on Android (without actively telling it to "sync"). Then change the file on Android, these 2nd changes are never sent back to the server unless you explicitly tell it to "sync" again, manually. That's what I mean with 2 way sync.

    There are quite a few files where you just need that to work to use them properly, like the database of a password manager as a prime example. Mine can talk to Nextcloud natively, so I don't need the client for that, but I was incredibly close to just switching to syncthing, if I didn't have active users that use the web office integration of Nextcloud.

  • I think the typical recommendation would be "the 100" (Link to GitHub). There are a few other projects like it. I think that should be a good starting point for a search though if that particular one is not your cup of tea.

    We're in the age of easily accessible, great quality hardware though. Just from a performance point, 3d printing will be worse in most respects comparatively (still "good enough" though if using a modem design). Look at a Voron V0 kit as an example (or one of the other printers for ants, if you're looking for more complexity). Uses nothing but readily accessible parts, reasonably priced and incredible performance.

  • Nextcloud can't do two-way sync on Android. At all. That's like core functionality for the product IMHO and there's a feature request open I think. When I found that out, I basically spit out my coffee. It's fine if you just want to upload photos you take, that kinda works (but my god is it fragile).

    Nextcloud is pretty good at quite a few things, including extensibility, but having some omissions in functionality that boggle the mind.

  • What else do you want from that email? You got a new subscriber. There's their name. Why change the layout just for the sake of change? Surely there are people having rules or automations tied to them, why brake them? Just for funsies?