Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment MTU (Score 1) 20

If people would just accept a decent MTU none of this would matter.
The max is 64 K but we're stuck with 1500 (including overhead) because you can't be sure that every hop will support your MTU.
Internally you can enable jumbo frames and shit will work, but once you need to go out over the internet all bets are off, so you limit your shit to 1500 and your performance goes to all hell.

We're basically delivering UHD movies via telegram.

Comment Re:Having trouble finding people? Really? (Score 2) 130

Like we're going to listen to a 6-digit UID noob on fucking Slashdot for advice on how to run our shit.

If you can't commit to the hours required then perhaps you should seek out another hobby. And honestly, if you knew what you were doing you wouldn't be dealing with emails 7 days a week or being hit with "personal insults". Further, those "insults" ARE about the code, in your case they happen to be about the shitty fucking code you keep submitting.

I'm Linus Torvalds, fuck you.

P.S. Why are we losing developers? 2016 is on track to be the year of the Linux desktop and we need more developers for when the masses adopt Linux and all he bugs and security holes are forced to the surface.

Comment Re:Will Use Neither (Score 1) 88

That "very definition" is used incorrectly by so many people, including you. When you're slapping it into a call to an encryption/decryption function, it's ALL effectively "something you know". A thumbprint hash is just data, so is a keyfile, so is the output of an RSA clock at any time. Security "experts" tried to model this off of physical security principles, but they don't translate over. That doesn't stop them all form parroting "something you know, something you have, and something you are hurr derp", though.

Something you HAVE and something you ARE need to be verified by some authority that controls access. It's like buying pseudoephedrine at the drug store. They ask for something you HAVE (your driver's license), and they verify it to a reasonable extent. Without an active arbiter, you can only use something you KNOW. Imagine buying pseudoephedrine on Amazon. That something you HAVE becomes something you KNOW because all you can do is type in your driver's license number, state, and expiration date. At the drugstore, they expect a physical card with a photo that looks like you and a magstripe that swipes with valid data. They can also physically see if you look like a tweaker who's got the shakes because they need another hit.

You can try to use automated arbiters, but they're vulnerable. A thumbprint scanner can be tricked into scanning a fake thumb or someone else's thumb, or it can be bypassed completely if you know the output it gives for your target thumb. A car with a breathalyser can be tricked by having someone else, or a raccoon, blow into it (that story was fake by the way - http://www.inquisitr.com/24605... ). Or, again, if you know what the breathalyser outputs on a good blow you can bypass it entirely.

You can try to use remote arbiters. A typical example is a security camera and a remote person monitoring and unlocking doors and shit. You can attack the camera, dress up as the target, put a photo of the empty hallway over the camera so that's all it sees, whatever. For an apartment gate/door with an intercom and a "buzz me in" system, you can pretend to be anyone to anyone who can buzz you in, or you can click the button a bunch and make the sound distorted and someone will just fucking buzz you in to make it stop, or you can always attack the gate.

Something you KNOW is the only thing you can use without an arbiter, because the mere knowledge of that thing is what constitutes valid access.
Something you ARE and something you HAVE require an arbiter for verification, otherwise the mere knowledge of those things can be used to masquerade/forge the thing that you ARE/HAVE. Automated and remote arbiters are better than nothing, but their automation/remote nature make them less able to verify the ARE/HAVE to the same degree an active and present arbiter can.

The most common "two factor" authentication systems in place are RSA clocks and one-time passwords sent via SMS.
No one verifies that you have and own that dongle with seed XYZ or that the specified phone number belongs to you. They verify that you know the code the dongle output or that you know the code they send you. Knowing either isn't very hard, and you can attack on either end.

RSA clocks: Attack the database that has the seeds and generate your own valid codes willy nilly. Steal the dongle. The easiest, however, is to pwn the target's device / MITM the target's network connection. When they're doing shit intercept the code and use it in your own attack (they all have pretty wide validity windows to account for clock skew, time for users to type it in, latency and processing time, etc.) This is why many places now require you two input two separate codes to disable the dongle - a victim will typically not provide 2 codes within a short time span. Of course this is pointless as the attacker can spoof a message to the victim saying the first code was rejected, try again. The user will do so immediately and the attacker now has 2 valid codes and can remove the dongle from the account.

SMS: You can attack the server that generates the codes, the service that sends out the SMS, steal the cell phone, or whatever. The easiest, however, is just downloading the SMS messages yourself - all you need to know is the target's phone number (SMS is incredibly insecure).

The RSA clocks are the better of the two since a successful attack requires either an active attacker or an undetected breach of the database containing the seeds. (Or breaking the algorithm.) But they are absolutely not "something you have" when you present the code. They are "something you know".

Comment Re:Will Use Neither (Score 1) 88

There is no such thing as two-factor encryption for cold data.

Using a keyfile and a password is the same thing as using a complex password. You just know one and you have the other and you chain them.
The same for using a password and thumbprint hash. Anyone who has the encrypted data and knows how it's encrypted can feed it the password and hash.
These are functionally no different than a single complex password - there is nothing "two factor" about it. And in many cases this type of layering can make it much easier for attackers to break ur shit.

Consider someone using 7-Zip to encrypt their "Secret My Little Pony Costume Design" directory.
1 layer of encryption using "aj29dn(3nb1A3n+d,c^D" is much better than 4 layers using "aj29d", "n(3nb", "1A3n+", and "d,c^D". The smaller passwords will be cracked almost instantly, and each one gets them 25% of the way to your shit. The full password will take ages to crack and it has to be done all or nothing.

You only want to layer passwords if your password's entropy exceeds the length (in bits) of the output of your encryption algorithm (or really, length minus one bit).
It's far more common to increase the number of rounds than it is to layer, but if you suspect an algorithm may be compromised it may make sense to use multiple layers with different algorithms. Layering also makes it easier to slap on plausible deniability and steganography.

Temporal passwords (RSA clocks) require a verification step by an arbiter. These are vulnerable to DoS attacks and MITM attacks, as well as all the usual "LOL HACKED UR DB AND GOT UR SHIT" attacks. Anyone with the seed of your particular authenticator app / dongle can generate those temporary codes and get access from the arbiter.
These kinds of passwords aren't there to protect the actual stored data, but control access to it. Anyone who gets the data will be able to try to decrypt it as usual.

For a temporary password to be considered a secondary layer of encryption, the data must be decrypted (temp pw layer only) and reencrypted each time that temporary password changes, AND you must ensure all previous copies of the decrypted AND encrypted data are destroyed (you can't do this if you hand the decrypted file to the user for them to decrypt the inner layer). You generally don't do this for cold data, you do it for live communication across an untrusted channel, such as the itnernet.

Comment Re:Will Use Neither (Score 1) 88

KeePass IS better. It's far more functional and far more customizable.
Throwing a KeePass database on Dropbox is secure even if Dropbox exposes the database.

I find it hilarious that you bitch about people who don't understand that LastPass's breaches meant nothing, yet you go on to imply that Dropbox's breaches are a problem for people using it for KeePass databases.

Comment Re:Okay, so 5G isn't 5G (Score 1) 54

No no no. We French fucks at SI dictate that G is for giga.

You can never use G for anything other than giga. g is for gram, but we don't use g for the base unit of mass, we arbitrarily use kg as the base unit for mass even though k is the prefix for 1000. However, 1000 kg isn't kkg, as our own rules dictate, but Mg, which is megagram. Note the capital M, we use big letters when we're scaling things up in magnitude and small letters when scaling them down.

Except for k, as noted previously, because K is for Kelvin. And also except for h and da. We'll gloss over h and da, as well as d and c, because we got drunk and included them even though every other prefix is based on powers of 1000. Yeah, we woke up next to da one morning and it wasn't pretty, I can't believe we included a prefix with two fucking letters when every other prefix is a single letter.

Back to M. M is MEGA and means 10^6, while m is milli and means 10^-3 (but M is also mass and m is also meter). Now, I know you thought that M being 10^6 would mean m was 10^-6, but it's not. (It's just not, okay?) For 10^-6 we use a u, but not a regular u that you can write or type easily, a squiggly ass Greek fuck of a u. This fucking guy: . Sure, we could have used u since it's not in use in any other base unit, dimension, or prefix, but fuck you, we're French.

But don't worry, is the only one like that, unless you count the dimension symbol for temperature, or the 2nd-tier named units where is for Ohm (we haven't used O but we were worried it might look like a 0 even though we dictate that you must put a space between quantities and units) while C is degree Celsius (because C is for coulomb).

Now, you might be thinking that we should have used c for coulomb and C for degree Celsius. I'm sure that capitalization led you to believe degree Celsius is named after someone whereas coulomb is not. In fact they are both named after people, but degree Celsius is the only named unit in the first or second tier of base units that has multiple words. We actually dictate that named units start with lower case letters except when any regular ass word would have its first letter capitalized, such as at the start of a sentence. However, since degree Celsius is two fucking words, we decided that Mr. Celsius would always be capitalized, just because. This left us with no choice but to use C for coulomb and C for degree Celsius. Of course when pluralizing degree Celsius we go to degrees Celsius, not degree Celsiuses, even though "degree Celsius" as a whole is the fucking term.

Where was I? Ah, yes, the . Don't worry, after we go to n, which is for nano, or 10^-9. This is the counterpart to G (for giga) which, as I explained previously, is only for giga and not the universal gravitational constant, so please get it right. It's all so simple and consistent!

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (7) Well, it's an excellent idea, but it would make the compilers too hard to write.