Two-factor authentication (T-FA) (or dual factor authentication) is any authentication protocol that requires two independent ways to establish identity and privileges.
Exactly, keyword being independent. Splitting one factor doesn't mean the thing is suddenly two-factor.
You can't just implement the concept of "something you have" by storing data on an external device instead of the computer, because the data is not bound to the external storage in any way. Something you have means something you must have. Duplicating a USB stick is trivial compared to a real token.
Your messing around with the implementation reminds me of cargo cult programming. You don't understand the concept so you mimic its implementation with something else, believing it has the same effect and security.
Sorry, but that's rubbish. This is just obscurity. The fact that you can get all the data without you knowing makes it 1-factor.
Data has the property that anyone can duplicate it without the owner knowing it was duplicated. You can neither prove that it was not duplicated nor that it was duplicated. A necessary property of 2-factor is having a component that you have to physically own. Data on a USB stick definitely does not meet this criterion.
An important part of 2-factor is that you can prove it's not compromised at the moment by simply holding the physical component in your hand. In the case of a USB stick you still have to second-guess whether you left it unattended somewhere or a trojan on your computer got to the data on it.
So again, for proper 2-factor it must not be possible to duplicate the physical component.
having a physical USB token with a TC volume (esp. the kind that stores things in a steganographic way) is in my opinion practically equivalent security-wise to the article's 2-factor authentication if you're smart enough to have your token on your keychain or something (a lot more likely than somebody will steal your laptop than your token IMHO).
No, it's not. Just because you have the data on a portable device and the data is fairly big or obscured, doesn't mean it's 2-factor. You are exposing the complete contents of your stick to the computer. Someone knowing this can duplicate your entire stick and from then on use it along with your sniffed password.
2-factor needs something in the stick that never leaves the stick, i.e. the stick itself must be calculating some public key crypto stuff and never expose its private key.
...the attempt to solve with technology what can't be solved by technology.
How about having social workers that deserve that job title? Do we soon replace all judgment on humans and human interaction with computers'?
It is this very dehumanization that causes violence among humans in the first place. How long until someone is flagged by this and it becomes a self-fulfilling prophecy because he feels trapped?
This whole anti-social project shouldn't even have started. What a waste.
Open Source pet-peeve: using a wiki for documentation. Expecting the users (the oh-so-often-spoken-of "community") to write your documentation for you is lazy.
I'm with you. There's nothing worse than projects who seem to have no design plan and just code ahead. Documentation is lacking and you have users guessing about the features. Most prominent example in my eyes is Asterisk.
Fortunately, wikis were used for this event only. I can understand that they wanted to have a process that allows for fast changes when doing such events.
Normally, NetBSD documentation is first class, be it man pages or documentation on their homepage. It's one of the few Open Source systems that properly documents everything. The whole NetBSD homepage is managed with CVS and written using DocBook I think. AFAIK they need to checkin to CVS and rebuild the relevant parts of their homepage with a "make" to change anything.
So for an event that lasts 3 days and where people need a rapidly changing status overview, the usual documentation progress probably was too slow.
Sure, I was just conveying the general idea. Optimally, you'd use something like openssl dgst -sha512 -binary and base64-encode the output, then take 16 or more chars from it.
This way, you'll increase entropy per character from 4 to almost 6 bits.
how long is it going to be before it becomes to not be profitable to make music?
I hope not long. This will weed out all the one-hit wonders and "popstar" puppets and leave only those musicians who make music for the sake of making music instead of making money.
How about an algorithm that doesn't let you forget it?
echo "user:domain:iteration:mastersecret" | md5
You only have to remember one secret and you can store the other triplets in the clear. Also, the entropy of your passwords is quite low with only 16 possibilities per character. How about having the hash in binary and piping it through base64? This way you'd have 62 possibilities per char.
You can do whatever you like with that until you stick it in a computer, then the license kicks in.
Fortunately, there are still countries that have sane laws and customer rights.
I buy something in a store, I can use it. I can crack it to make backups. I can disassemble it. And the vendor can go fuck himself, his EULA and his lawyer army.
They're just using MD5, which you could reproduce on any computer. In fact, that's how I generate _all_ my passwords:
echo "user:domain:iteration:masterpass" | binary hash | base64 | take first 16 characters
It's a simple algorithm which you don't need to keep secret. Also, you can write down the made-up user/domain/iteration triplets. All you need to keep secure is the master password. Thanks to the iteration, you can lose a generated password without affecting the secrecy of your master password or all the other passwords.
A simpler version would be to take the ASCII hash directly as a password. However, using a binary hash and base64-encoding it allows you to cram more entropy per character into the resulting password.
I buy new ones when they have double the capacity of the old ones and provide the most bang for the buck. Most of the time the old ones still have some months of warranty left and you get some cash to finance the new ones.
Right now I'm at 320G drives - most bang for the buck.
Do people really think Windows does a good job with backward compatibility?
On the surface, yes of course. You can run old programs on newer versions of Windows.
What you certainly don't want to ever do, though, is looking under the hood of Windows. That's where they failed completely. To support this backward compatibility and because they did a lousy job of designing their system, Microsoft has to drag along gazillions of quirks and hacks.
NAT forces a 100%, unless specifically changed, inbound packet filter.
That's just plain wrong. Send a packet with a spoofed source address to a NAT-only host and watch the reply bounce into the LAN which should not happen with a proper filter. Any malicious ISP could set a route to your internal LAN via your public address and have complete access to all your LAN hosts. The reason why this probably wouldn't work is that most decent devices already contain a stateful packet filter in addition to NAT. Remove the NAT and nothing changes.
Without NAT users would use no packet filtering at all, just look at what most users who directly connect to their ISPs modems do.
How did we go from router hardware to hosts doing the connection themselves? Of course, if the host is directly connected, it's responsible for its own security. What has that got to do with a router and a stateful filter therein?
The whole fucking point is that without NAT home users would NOT use any packet filtering, or at best some half assed automatic one which doesn't do anything.
The filter is in the same little box that Joe Public installs and then forgets. Nothing would change from a dumb user's perspective! Any "half-assed automatic" stateful packet filter which allows only outbound connections is enough to get the same security we already have through NAT+filter, only without NAT.
NAT is useless for security. It gets boring to repeat but apparently it's necessary in order to fight the FUD surrounding NAT's removal.
Those 2 comments contradict themselves. How can it make things SOO much harder for legitimate things, but not make it any harder for illicit things?
That's only if you (wrongly) assume that the security comes from NAT in the first place. It doesn't, hence it makes perfect sense.
1. NAT+packet filter: NAT prevents many things from working, filter protects user.
2. packet filter: many things work, user is still protected.
Off the top of my head, if something installs a trojan, the hacker needs to know what IP to connect to - that information could be slotted into an innocent looking email, sent via the isp. With Nat, the trojan has no choice but to open a direct connection to somewhere so the ip can be logged - far more likely to be spotted by local firewall security on the pc.
You are clinging to a tiny piece of obscurity when your security has already been circumvented entirely. You say it yourself, there's malicious code running on the machine. How can you trust the "firewall" on the PC itself to be even working?
I dislike NAT, but I do stand by my original statements, that in the broader scheme of things, it has helped secure joe public more than if he didn't have it.
Maybe you don't understand NAT enough to see that it absolutely makes no difference security-wise. NAT's "security" really comes from packet filters which can work without NAT just as well.
In SUSE (and perhaps other distro's as well) surfing is extremely slow, untill you turn off IPv6.
I suppose "surfing is extremely slow" is really meaning "DNS lookups take very long" or something like that. Or is your throughput really lower?
Strange that the BSDs doesn't have those ridiculous problems. If you aren't connected via IPv6, there should be no default route for IPv6 and applications ought to fall back to IPv4 immediately.
Check with netstat -rn whether that's the case or not. If there is no default route for IPv6 and you still get delays, there's something else amiss. But it's not the fault of IPv6. Go blame Linux amateurs maybe.
Yes, NAT can be a pain in the butt, but it HAS helped keep Joe Public a little bit more secure!
That's a flawed argument. Getting rid of NAT changes absolutely nothing security-wise for Joe Public, while making many other things easier or even possible in the first place.
Also, unlike a firewall, some viruses and things which may need to determine their 'public' IP address will find the situation harder behind a nat.
What are you arguing here? There's no gain or loss in security, whether viruses know the public address or not.
There should be some law where anyone defending NAT in a discussion loses by default. It's sickening to read this crap over and over again.
NAT is a PITA with no gain in security. That perceived security comes from packet filters which don't need NAT or have anything to do with it.
You can't just implement the concept of "something you have" by storing data on an external device instead of the computer, because the data is not bound to the external storage in any way. Something you have means something you must have. Duplicating a USB stick is trivial compared to a real token.
Your messing around with the implementation reminds me of cargo cult programming. You don't understand the concept so you mimic its implementation with something else, believing it has the same effect and security.
That's the same obscurity the parent presented.
All the keys would represent the one secret you know. There is no part in it that you have to own. Hence it's not 2-factor.
Sorry, but that's rubbish. This is just obscurity. The fact that you can get all the data without you knowing makes it 1-factor.
Data has the property that anyone can duplicate it without the owner knowing it was duplicated. You can neither prove that it was not duplicated nor that it was duplicated. A necessary property of 2-factor is having a component that you have to physically own. Data on a USB stick definitely does not meet this criterion.
An important part of 2-factor is that you can prove it's not compromised at the moment by simply holding the physical component in your hand. In the case of a USB stick you still have to second-guess whether you left it unattended somewhere or a trojan on your computer got to the data on it.
So again, for proper 2-factor it must not be possible to duplicate the physical component.
Grand-parent's idea is stupid. Unless you're Bruce Schneier, you probably won't be able to judge a security system properly.
Does that mean everyone only needs security that he himself can't break? No, everyone needs security that noone can break.
2-factor needs something in the stick that never leaves the stick, i.e. the stick itself must be calculating some public key crypto stuff and never expose its private key.
Not music is or is not lossless. A (conversion) process is or is not lossless.
...the attempt to solve with technology what can't be solved by technology.
How about having social workers that deserve that job title? Do we soon replace all judgment on humans and human interaction with computers'?
It is this very dehumanization that causes violence among humans in the first place. How long until someone is flagged by this and it becomes a self-fulfilling prophecy because he feels trapped?
This whole anti-social project shouldn't even have started. What a waste.
Fortunately, wikis were used for this event only. I can understand that they wanted to have a process that allows for fast changes when doing such events.
Normally, NetBSD documentation is first class, be it man pages or documentation on their homepage. It's one of the few Open Source systems that properly documents everything. The whole NetBSD homepage is managed with CVS and written using DocBook I think. AFAIK they need to checkin to CVS and rebuild the relevant parts of their homepage with a "make" to change anything.
So for an event that lasts 3 days and where people need a rapidly changing status overview, the usual documentation progress probably was too slow.
Sure, I was just conveying the general idea. Optimally, you'd use something like openssl dgst -sha512 -binary and base64-encode the output, then take 16 or more chars from it.
This way, you'll increase entropy per character from 4 to almost 6 bits.
The best music is made with passion not greed.
How about an algorithm that doesn't let you forget it?
echo "user:domain:iteration:mastersecret" | md5
You only have to remember one secret and you can store the other triplets in the clear. Also, the entropy of your passwords is quite low with only 16 possibilities per character. How about having the hash in binary and piping it through base64? This way you'd have 62 possibilities per char.
That's a lie. The own neither of all those domains.
I buy something in a store, I can use it. I can crack it to make backups. I can disassemble it. And the vendor can go fuck himself, his EULA and his lawyer army.
Simple as that.
They're just using MD5, which you could reproduce on any computer. In fact, that's how I generate _all_ my passwords:
echo "user:domain:iteration:masterpass" | binary hash | base64 | take first 16 characters
It's a simple algorithm which you don't need to keep secret. Also, you can write down the made-up user/domain/iteration triplets. All you need to keep secure is the master password. Thanks to the iteration, you can lose a generated password without affecting the secrecy of your master password or all the other passwords.
A simpler version would be to take the ASCII hash directly as a password. However, using a binary hash and base64-encoding it allows you to cram more entropy per character into the resulting password.
And that's bad how?
*I*'m using Firefox with noscript and didn't get the spam/pop-ups/redirects. Allow Javascript only for wontonway.com and you're fine.
I buy new ones when they have double the capacity of the old ones and provide the most bang for the buck. Most of the time the old ones still have some months of warranty left and you get some cash to finance the new ones.
Right now I'm at 320G drives - most bang for the buck.
You know why allergies exist? Among other things, because parents try to keep their children as far away from bacteria and dirt as possible.
The strongest system is the one continuously exposed to threats and adapting to them.
What you certainly don't want to ever do, though, is looking under the hood of Windows. That's where they failed completely. To support this backward compatibility and because they did a lousy job of designing their system, Microsoft has to drag along gazillions of quirks and hacks.
Congratulations, you just reinvented microkernels (poorly).
How did we go from router hardware to hosts doing the connection themselves? Of course, if the host is directly connected, it's responsible for its own security. What has that got to do with a router and a stateful filter therein?
The filter is in the same little box that Joe Public installs and then forgets. Nothing would change from a dumb user's perspective! Any "half-assed automatic" stateful packet filter which allows only outbound connections is enough to get the same security we already have through NAT+filter, only without NAT.
NAT is useless for security. It gets boring to repeat but apparently it's necessary in order to fight the FUD surrounding NAT's removal.
1. NAT+packet filter: NAT prevents many things from working, filter protects user.
2. packet filter: many things work, user is still protected.
You are clinging to a tiny piece of obscurity when your security has already been circumvented entirely. You say it yourself, there's malicious code running on the machine. How can you trust the "firewall" on the PC itself to be even working?
Maybe you don't understand NAT enough to see that it absolutely makes no difference security-wise. NAT's "security" really comes from packet filters which can work without NAT just as well.
Strange that the BSDs doesn't have those ridiculous problems. If you aren't connected via IPv6, there should be no default route for IPv6 and applications ought to fall back to IPv4 immediately.
Check with netstat -rn whether that's the case or not. If there is no default route for IPv6 and you still get delays, there's something else amiss. But it's not the fault of IPv6. Go blame Linux amateurs maybe.
That's a flawed argument. Getting rid of NAT changes absolutely nothing security-wise for Joe Public, while making many other things easier or even possible in the first place.
What are you arguing here? There's no gain or loss in security, whether viruses know the public address or not.
There should be some law where anyone defending NAT in a discussion loses by default. It's sickening to read this crap over and over again.
NAT is a PITA with no gain in security. That perceived security comes from packet filters which don't need NAT or have anything to do with it.
http://www.isohunt.com/download/14712136/hacking+d emocracy