Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Delayed Password Disclosure

Zonk posted more than 9 years ago | from the you-show-me-yours dept.

Security 163

ET_Fleshy writes "Markus Jakobsson has an interesting article discussing a promising new security protocol called "Delayed Password Disclosure" that can validate a computers authenticity before exchanging passwords/keys. While nothing is ever truly secure, this seems to show promise in protecting users from a wide variety of stealth attacks (pdf) used today, specifically man in the middle (pdf) attacks."

Sorry! There are no comments related to the filter you selected.

And this is new how??? (4, Insightful)

SeanTobin (138474) | more than 9 years ago | (#11749371)

Forgive me for not reading my latest issue of Cryptographer weekly but how on earth is this any different than RSA fingerprints? It looks like the "envelope" and "carbon paper" are just elements of a pre-shared key anyway.

If you know the fingerprint of the host you are connecting to, you are more or less immune from man-in-the-middle attacks. If you have never communicated with the host before, nothing is going to stop a man-in-the-middle - especially if you have to magically share locations of "carbon paper" without the man-in-the-middle knowing about it.

Re:And this is new how??? (0)

mboverload (657893) | more than 9 years ago | (#11749532)

I almost had a joke...but no.

Re:And this is new how??? (1)

Profane MuthaFucka (574406) | more than 9 years ago | (#11749662)

It's different because it's less secure than a public key signing system. Oh wait, that's not good.

It's different because it uses a carbon paper template. I suppose that to authenticate an e-mail, you'd put the thing on your computer screen. What if it's not the right size? Oops, that's not good either. False negative authentication makes it impossible to trust. That's not good either.

Maybe this is yet another invention just waiting to be patented, since only unoriginal inventions can get a patent these days.

Re:And this is new how??? (5, Informative)

GreyPoopon (411036) | more than 9 years ago | (#11749968)

If you know the fingerprint of the host you are connecting to, you are more or less immune from man-in-the-middle attacks. If you have never communicated with the host before, nothing is going to stop a man-in-the-middle - especially if you have to magically share locations of "carbon paper" without the man-in-the-middle knowing about it.

It actually provides a technique of verifying th authenticity of a host with whom your computer has never communicated. The host, presumably, knows your password (or a salted-hash representation). The host either obtained this via connection with another computer at some time in the past, or by some information that you provided when signing up for whatever the service is (think bank). The host uses what it knows about your password to send you specially encoded information that, in combination with what *you* also know about your password can be used to verify that at the very least you aren't giving your password to a system that doesn't already have that information. You can also think of this method as a decent way to validate RSA fingerprints by a system that hasn't already been seeded with pre-shared keys.

Re:And this is new how??? (1)

Dwonis (52652) | more than 8 years ago | (#11750547)

Ah, so it's no different than Kerberos? (Disclaimer: I haven't RTFA.)

Re:And this is new how??? (1)

Goaway (82658) | more than 8 years ago | (#11750634)

And why wouldn't I just encrypt my traffic with the password both the server and I know, thus eliminating both man-in-the-middle attacks, and establishing trust, without ever exchanging keys?

Re:And this is new how??? (0)

Anonymous Coward | more than 9 years ago | (#11750048)

Indeed, almost any kind of mutual authentication with pre-shared secrets eliminates the man-in-the-middle (unless of course the attacker has the secret).

I guess this just has the advantage of computationally inexpensive authentication (whatever that's worth these days).

I have met the man in the middle. (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11749379)

And he is me, appearently.

"Nothing to see here. Move along."

Re:I have met the man in the middle. (2, Interesting)

billimad (629204) | more than 9 years ago | (#11749578)

And he is me, appearently

You take it in both ends then AC? I respect your i/o capabilities ;-)

Re:I have met the man in the middle. (0)

Anonymous Coward | more than 9 years ago | (#11749688)

I believe it is called "Pegging".

http://en.wikipedia.org/wiki/Pegging_(sexual_pract ice) [wikipedia.org] .

Bigger problem is... (5, Interesting)

fembots (753724) | more than 9 years ago | (#11749394)

There are enough people who will give away plain-text password unsuspiciously over the phone or internet.

My bank (and probably many others) will block an account after three consecutive failed authentication, so any guesswork is going to be hard for the bad guys.

Your sig (0)

Anonymous Coward | more than 9 years ago | (#11749500)

Joined the Rock Paper Scissors Tournament yet? [iclod.com]

Too complicated, let's just play.

Rock.

Re:Your sig (1)

Mr. Capris (839522) | more than 9 years ago | (#11749519)

Paper! I win!

Re:Your sig (0, Offtopic)

mboverload (657893) | more than 9 years ago | (#11749554)

Just so people know Wikipedia and its projects are back up. However, I'm gettin alot of server errors and its really slow =(

Best two out of three? (0)

Anonymous Coward | more than 9 years ago | (#11749603)

Re:Your sig (1)

tdelaney (458893) | more than 9 years ago | (#11749704)

Paperless! I win!

Re:Your sig (1)

fembots (753724) | more than 9 years ago | (#11749551)

Just play as a guest [iclod.com] then.

Re:Your sig (0)

Anonymous Coward | more than 9 years ago | (#11749580)

Scissors.

Aw, crap.

Lockout after failed auths is a DoS (3, Insightful)

tepples (727027) | more than 9 years ago | (#11749507)

My bank (and probably many others) will block an account after three consecutive failed authentication

This is a big hole for denial of service. Try purposely logging into the bank CEO's account with a bad password, and see how quickly the policy is changed.

Re:Lockout after failed auths is a DoS (2, Interesting)

the pickle (261584) | more than 9 years ago | (#11749724)

Not if they block an IP rather than a login name, which is the smart thing to do (and the way it's been implemented where I've seen it).

p

Re:Lockout after failed auths is a DoS (1)

thedustbustr (848311) | more than 9 years ago | (#11749788)

Even better would be to simply enforce a 3 second delay between login attempts... as is mainstream in practically any nix box, and winXP to a certain extent. WinXP is more like 3 instant attempts with an 8 second delay.

Re:Lockout after failed auths is a DoS (2, Interesting)

jacksonj04 (800021) | more than 9 years ago | (#11750064)

WinXP (depending on configuration) will get continually longer lockouts, exponentially increasing. After 3 or 4 bad logins it's bearable but after 6 or 7 you're looking at 5 minute waits.

Re:Lockout after failed auths is a DoS (1)

nbert (785663) | more than 9 years ago | (#11749892)

That's obviously not the smart way to do it. Just use a high number of proxies and switch to the next one after 2 attempts failed.

And now guess how programs like wwwhack work since about a decade...

Re:Lockout after failed auths is a DoS (2, Interesting)

modecx (130548) | more than 9 years ago | (#11749744)

And just how would you guess/know anyones' usernames , especially without also knowing their passwords?

Personally, my bank usernames look like a chunk taken out of some top-secret military encoded spy message--pretty much like the password that goes with it... I think it's a good practice to obfuscate usernames as much as passwords. It's about as likely that stream of space born gamma rays would trigger my account as it is that an actual person or computer would.

Re:Lockout after failed auths is a DoS (1)

Taladar (717494) | more than 8 years ago | (#11750385)

Actually it is a bad idea as customers are more likely to save those names in a file to copy&paste them if they are totally unreadable.

Re:Lockout after failed auths is a DoS (1)

alpha_foobar (820088) | more than 8 years ago | (#11750647)


I thought the parent was referring to the username being encrypted? Just like the password.

I mean, if his password looked like some huge chunk of encoded text... how on earth would anybody remember it?? I presume his bank does this client side, then transports it via https?

This way the bank users only have to remember stuff that is possible for joe blogs to remember... but a level of hightened security is still achieved.

Re:Lockout after failed auths is a DoS (1)

tepples (727027) | more than 9 years ago | (#11750707)

Personally, my bank usernames look like a chunk taken out of some top-secret military encoded spy message--pretty much like the password that goes with it

So what happens when you want someone to send you money? I thought part of the definition of "username" was that it is the public token for others who want to interact with you to identify you.

Re:Bigger problem is... (2, Insightful)

AviLazar (741826) | more than 9 years ago | (#11749681)

You gotta love the banks that utilize a person's social, followed by a four digit pin, and unlimited tries.

Word (0)

Anonymous Coward | more than 9 years ago | (#11749395)

<html xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o=" urn:schemas-microsoft-com:office:office"
xmlns:w= "urn:schemas-microsoft-com:office:word"
xmlns="ht tp://www.w3.org/TR/REC-html40">
Does it delay macro viruses?

An okay article, I guess.... (5, Funny)

aendeuryu (844048) | more than 9 years ago | (#11749400)

It'd be better if the font weren't so small, though...

Re:An okay article, I guess.... (2, Informative)

mrnobo1024 (464702) | more than 9 years ago | (#11749590)

In IE and Firefox, you can hold down ctrl and move the mouse wheel to change the font size.

Re:An okay article, I guess.... (0)

Anonymous Coward | more than 9 years ago | (#11749854)

Hot damn, that is totally cool! Never knew this.

Re:An okay article, I guess.... (1)

Taladar (717494) | more than 8 years ago | (#11750431)

Works in Opera too although here it simply changes the Zoom Factor (size of everything, not just font-size).

Re:An okay article, I guess.... (4, Funny)

athakur999 (44340) | more than 9 years ago | (#11749749)

No kidding. He's just asking for Slashdotting since his server has transfer all those big characters.

Re:An okay article, I guess.... (1)

bow (300451) | more than 9 years ago | (#11749754)


<meta name=Generator content="Microsoft Word 11">

Well, using MS Word for html authoring might not be the best idea :)

Re:An okay article, I guess.... (1)

s88 (255181) | more than 9 years ago | (#11750830)

I agree. Also, why pick a name like "ÒDelayed Password DisclosureÓ", and use example with names like "AliceÕs"? I like the irish as much as the next guy, but come on.

Nothing new to see here. Move on. (5, Interesting)

TechyImmigrant (175943) | more than 9 years ago | (#11749415)

Mutual authentication is nothing new. There exist many mutual authentication schemes that are resistant to man in the middle attacks and also ensure liveness of the exchanges.

The one described here looks to be a simple shared secret method. In may situations, certificate based methods are used in order to avoid the need to securely distribute a shared secret ahead of time.

For a shared secret based mutual auth, why not do the normal thing and pass random numbers and their hashes back and forth, mixed in with the challenge-response sequences needed to establish an authenticated identity, a shared session secret and liveness? Read various EAP drafts or 802.11i or recent 802.16e drafts for real world examples of how to do this. The details necessarily change with the context.

These methods have the benefit of lots of analysis by the crypto community. This delayed password disclosure scheme doesn't seem to have the same benefit.

Sharing keys? (4, Insightful)

nizo (81281) | more than 9 years ago | (#11749418)

Thus spake the article:
Note that use of encryption software, such as SSH, does not address this problem, since the attacker simply can replace the public keys of the two parties with public keys for which it knows the secret keys. This results in the two parties sharing keys with the attacker, as opposed to with each other; as a consequence, the attacker will be able to read (and even modify) all traffic before re-encrypting it and forwarding it.

And this is why you always share public keys via some other secure means (USB drive, cd, floppy), at least in an ideal world. The article talks about this in regards to someone transmitting data to their bank, however if I am not mistaken SSL(not mentioned in the article) already takes care of this kind of attack. Somehow I doubt any joe user is using SSH to authenticate with their bank :-)

Re:Sharing keys? (5, Interesting)

slavemowgli (585321) | more than 9 years ago | (#11749484)

SSL (ideally) gives you the ability to do that, at least. I had one professor (giving network engineering / security classes) who said that at times, he actually called banks etc. whose websites he'd used and asked them to confirm the SSL certificate fingerprints etc. It always confused the hell out of them, but it worked. :)

Re:Sharing keys? (1)

ticktockticktock (772894) | more than 9 years ago | (#11749541)

Bank employees know what SSL is?

Re:Sharing keys? (1)

slavemowgli (585321) | more than 9 years ago | (#11749640)

Not all, I guess, but if you get to the right person...

Re:Sharing keys? (0)

Anonymous Coward | more than 9 years ago | (#11750698)

And this is why you always share public keys via some other secure means[...]

A public key is a public key.

Quick Question (1)

Troll-a-holic (823973) | more than 9 years ago | (#11749419)

Why is it called Man-in-the-middle?

Isn't it better if it were called Woman-in-the-middle? It would atleast not make us geeks seem so gay.

Re:Quick Question (4, Funny)

wfberg (24378) | more than 9 years ago | (#11749462)

Why is it called Man-in-the-middle?

Isn't it better if it were called Woman-in-the-middle? It would atleast not make us geeks seem so gay.


Well, feminist do-gooders, in an effort to de-genderify the term whilst keeping the acronym MITM beat you to it, by redefining MITM as "Meet-In-The-Middle".

It was a quite popular term in academia, until it was discovered that "Meat-In-The-Middle" in the context of a three-party situation sounds a lot more gay even.

Re:Quick Question (0)

Anonymous Coward | more than 9 years ago | (#11749812)

I realize this is a joke, but people reading should know that meet-in-the-middle [wikibooks.org] is indeed a type of cryptographic attack. It has nothing to do with man-in-the-middle, which attacks a protocol instead of a cryptographic algorithm.

Re:Quick Question (1)

tyler_larson (558763) | more than 9 years ago | (#11750763)

Well, feminist do-gooders, in an effort to de-genderify the term whilst keeping the acronym MITM beat you to it, by redefining MITM as "Meet-In-The-Middle".

It was a quite popular term in academia, until it was discovered that "Meat-In-The-Middle" in the context of a three-party situation sounds a lot more gay even.

There's another rendering of MITM that gets thrown around occasionally: "Monkey in the Middle".

It doesn't sound gay.. but it does sound a bit, um, different.

i play man in the middle (-1, Troll)

Anonymous Coward | more than 9 years ago | (#11749426)

with your mom.

Re:i play man in the middle (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11749805)

And take his dad in your ass, right?

Repeat after me: (0, Offtopic)

Anonymous Coward | more than 9 years ago | (#11749428)

"One time pads are not the answer."

"new"? really? (1)

prurientknave (820507) | more than 9 years ago | (#11749430)

I wonder if the type of people that came up with 'blink' are now writing new crypto protocols.

I think I'll just withdraw my deposit in gold bricks and sleep on it.

This sounds pretty interesting. (5, Funny)

Sheetrock (152993) | more than 9 years ago | (#11749456)

The only part I can't figure out is how they're going to send the carbon paper and envelopes across the Internet. I can't find the protocol for that.

Re:This sounds pretty interesting. (1)

IMarvinTPA (104941) | more than 9 years ago | (#11749560)

I'm not certain, but I'm sure CPIP [rfc-archive.org] may help.

IMarv

Re:This sounds pretty interesting. (1)

the pickle (261584) | more than 9 years ago | (#11749738)

RFC 1149 [faqs.org] , man.

p

Re:This sounds pretty interesting. (1)

ajs (35943) | more than 9 years ago | (#11749775)

carrier pigeon [faqs.org]

Re:This sounds pretty interesting. (0)

Anonymous Coward | more than 8 years ago | (#11750235)

Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.

Dude... that's Yoda, not Spock.

Re:This sounds pretty interesting. (0)

Anonymous Coward | more than 8 years ago | (#11750338)

No shit...and it's MR. Spock! Dr. Spock was a child psychologist or something!

And how is this better than existing tech? (1)

Aaron Denney (123626) | more than 9 years ago | (#11749473)

such as SRP?

Breakdown (3, Interesting)

MasTRE (588396) | more than 9 years ago | (#11749474)

This basically verifies that the party you are conversing with knows your password, or something about it (i.e. has a salted hash of your password), _before_ you input your password. One could argue that this is more secure than (poorly-implemented) channel security via PKI as a man-in-the-middle would not have access to the accounts hash table unless the target system was compromised.

Interesting, but there are probably a million such things you can do to further tighten security.

Re:Breakdown (0)

Anonymous Coward | more than 9 years ago | (#11750006)

Couldn't eve, after recieving many (say 100) 'magic envolopes' almost trivially open them, read alice's hash, crack it, and have alice's pasword?

I don't see how this could work... (2, Insightful)

smug_lisp_weenie (824771) | more than 9 years ago | (#11749493)

I'm no cryptography expert, but the secret positions of the carbon paper need to go into "an envelope only Alice can open"- Nowhere in this essay is it explained how this "envelope" is created technologically or how the recipient can interact with it, making the analogy pretty useless (unless I'm missing something). Also, it says that SSH doesn't help with man-in-the-middle attacks, but a third party signing agency, I believe, solves that problem, from what I understand. This "envelope" sounds suspiciously how quantum cryptography works- Is this just an explanation of "quantum cryptography" without mentioning "quantum cryptography"? I'm confused...

Re:I don't see how this could work... (3, Informative)

Sheetrock (152993) | more than 9 years ago | (#11749679)

I have not seen the implementation, so I am only speculating.

I believe that, in this case, Alice could generate the contents of said envelope with her public key, then send both the envelope and the key to the remote host. That host would respond with its positions, encrypt those with Alice's public key as well, and return the whole bunch to Alice who then decrypts everything with her private key.

There's something missing in my speculation -- why does Alice need to send anything but her public key?

Re:I don't see how this could work... (1)

haagmm (859285) | more than 8 years ago | (#11750351)

The key to the whole thing is the carbon paper only shows the numbers written over the password.

yes this does sound similar to quantum encription, however it is possible with non quantum technology, "an envelope only Alice can open" is as the above said encripted with Alice's public key. However, no one is looking at how the carbon paper is in the computer world.

actually, if you think of say an array of as many longs as the pasword has bits, and for each pasword bit you know to look at the two Most Signigant Bytes or the two least signifigant bytes. this can be encripted with alice's public key and sent back to her. She then decripts it with her private key, since she knows her password she knows to look at the proper "half" of each array eliment, and ensure they add to 0.

stop me if that sounds crazy

Re:I don't see how this could work... (1)

grennis (344262) | more than 8 years ago | (#11750616)

Yes, you are missing something.

1. You don't know about public key cryptography
2. Therefore you don't know much about cryptography at all
3. You are posting on slashdot about something you know nothing about
4. You used the word "quantum"
5. Despite (3), but as a result of (4), you get modded up
6. Therefore I read your silly post despite browsing at +1
7. I have now wasted the last 120 seconds of my life.
8. You now owe me approximately $2
9. I Profit!!!! Q.E.D.

An Opportunity to Rant. (5, Interesting)

TechyImmigrant (175943) | more than 9 years ago | (#11749527)

What the world does not need is another generalized mutual authentication method. These are used to place a veneer of security on a generally insecure thing.

E.G. Credit card transactions over the internet. These are protected by SSL/TLS. This is somewhat removed from the credit card transaction itself, instead protecting the link rather than the transaction. So you log onto vendorX's web site and use certs with SSL/TLS to protect the link. You feel conforted by the little lock icon in the corner of your screen and proceed to hand VendorX all the details needed to drain arbitary amounts of money from your credit card.

Instead.. Protect the transaction directly, with something like a secure credit card transaction protocol. VendorX doesn't need your credit card details, he needs your money. The security protocols should run between you and the vendor to establish a transaction and the vendor's identity, between you and your credit card company to authorize a payment against the transaction to VendorX and between the credit card company and VendorX to transfer the payment.

VendorX gets the money, not a blank, signed cheque.

Repeat exercise for all activities you need to secure, applying appropriate measures for the situation. Leave SSL/TLS for securing the link, not the application.

Re:An Opportunity to Rant. (3, Informative)

Wesley Felter (138342) | more than 9 years ago | (#11749692)

Instead.. Protect the transaction directly, with something like a secure credit card transaction protocol.

That was called SET. It failed because it was expensive and credit card fraud is already pretty low.

Re:An Opportunity to Rant. (1)

notsoanonymouscoward (102492) | more than 9 years ago | (#11749816)

this can also be accomplished w/ virtual CC numbers.

Re:An Opportunity to Rant. (2, Interesting)

ajs (35943) | more than 9 years ago | (#11749891)

Of course, what you suggest could be done without having to introduce special transaction elements between the customer and credit card vendor. You can simply use encryption here.
encrypt(Kvendor, "Authorize $20 to [vendor] from account 000001 at bank foo")
encrypt(Kvendor, encrypt(Kbankfoo, sign(Kself, "Authorize $20 to [vendor] from account 000001 at bank foo")))
SSL can easily serve all of these purposes. Of course, you would not send exactly the same message to both (this makes a known-plaintext attack possible).

Re:An Opportunity to Rant. (1)

droopycom (470921) | more than 9 years ago | (#11750032)

I assume that then the vendor would send:

encrypt(Kbankfoo, sign(Kself, "Authorize $20 to [vendor] from account 000001 at bank foo"))

to the bank...

But how does the vendor knows that you didnt sent him:
encrypt(Kbankfoo, sign(Kself, "Authorize $2 to [vendor] from account 000001 at bank foo"))

?

And why would you not just send:

encrypt(Kvendor, sign(Kself, "Authorize $20 to [vendor] from account 000001 at bank foo"))

And let the vendor send :
encrypt(Kbankfoo, sign(Kself, "Authorize $20 to [vendor] from account 000001 at bank foo"))
to the bank ?

Re:An Opportunity to Rant. (1)

Mr. Slippery (47854) | more than 8 years ago | (#11750207)

But how does the vendor knows that you didnt sent him: encrypt(Kbankfoo, sign(Kself, "Authorize $2 to [vendor] from account 000001 at bank foo"))

Cryptographic cut-and-choose protocols.

Bascially, you send 100 sealed (encrypted), but unsigned, money orders to the vendor. The vendor picks 99 of them, and says "Open these". You do (you provide the decryption keys), he sees that they're all for $200, so he has a pretty good assurance that the 100th is also for $200. You sign the 100th.

You're sort of signing through the envelope, so the metaphor breaks down (I guess you can imagine a piece of carbon paper in there)...actually what's involved are, IIRC, "blinded" crytographic signatures. See Schneider's Applied Cryptography [schneier.com] for the gory details.

Slashdotted (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11749528)

Mirror Here [tinyurl.com]

Re:Slashdotted (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11749576)

hee hee hee! I like pie!

I don't get it (3, Interesting)

lampajoo (841845) | more than 9 years ago | (#11749534)

Could someone explain to me how you implement carbon paper, "magic envelopes" and invisible ink inside of a computer? seriously...

Also, it seems like you could come up with an algorithm to make password guesses based upon the numbers that were returned...trying different values that add up to zero. Or would this take too long?

Re:I don't get it (2, Interesting)

0123456 (636235) | more than 9 years ago | (#11749566)

"Could someone explain to me how you implement carbon paper, "magic envelopes" and invisible ink inside of a computer?"

It's a metaphor. As far as I can see, the bank would calculate a matrix of numbers and send that to Alice, who would use the bit-pattern from her password to find the correct numbers to use for the key.

However, as has been pointed out, if the bank knows her password, it can simply send her the session key encrypted with her password, which will be impossible for the man-in-the-middle to crack (otherwise they could just use the password to log in!). So it's a bit of a pointless exercise.

Re:I don't get it (1)

lampajoo (841845) | more than 9 years ago | (#11749983)

lol, yeah I got that it was a metaphor. So Alice sending the magic envelope with carbon paper in it to the bank was pointless? Why did he include all that junk about the envelope and the invisible ink then?

X.509 Certificates? (3, Insightful)

Anonymous Coward | more than 9 years ago | (#11749535)

X.509 Certificates have been known for ages. There's nothing to see here. Please move along.

Huge text (0, Redundant)

hab136 (30884) | more than 9 years ago | (#11749583)

Holy crap that is some seriously large text!

Re:Huge text (0)

Anonymous Coward | more than 9 years ago | (#11749847)

HOLY CRAP IS THAT A LARGE GOATSE RIGHT IN YOUR SHITFUCKING FACE!

And I fucking goddammmm yell alll the time SLASHDOT. Jewish bastards y'all. Who was the guy that invented the earthquake-machine, huh? Who the fuck rocks all muslim countries with quakes? Who kills 200k Indonesians, 20k Iranians with a seemingly innocent quake? Who's nexz? North Korea?

Quite huge. (1)

game kid (805301) | more than 9 years ago | (#11749938)

Now even the nearsighted can learn about securing their Beowulf Clusters! (I'm myopic too so don't hurt me now.)

Seriously, even after RTFA, especially the last part that actually describes the proc in the first place, it's a bit hard for me to understand. I know it involves the server knowing what places the actual password resides within the user's "password" transmission...right?

Challenge-response for mutual authentication (1)

MobyDisk (75490) | more than 9 years ago | (#11749605)

The article describes a (new?) challenge-response authentication algorithm.

Cutesy Layperson Explanations instead of math (2, Interesting)

billstewart (78916) | more than 9 years ago | (#11749746)

Has anybody bothered getting the actual paper from these people instead of the cutesy descriptions of envelopes, red/green ink, and carbon paper? The authors go out of their way to write a cutesy layperson's description of their work, but they've obfuscated the real math inside envelopes full of carbon paper (assuming that some of their readers are old enough to remember using carbon paper), instead of just giving us the math.

So nobody technical can tell if they've really done anything new or interesting, or if they've just done Yet Another Variant on mutual authentication that doesn't offer any advantages over existing techniques. MITM attacks aren't new, and needing twoway authentication for some applications isn't new, and using stolen passwords to crack machines isn't new, and using cracked machines to do Bad Things with isn't too new, though the popular approaches to cracking Windows machines don't usually bother with MITMing passwords because there are so many other back doors available. So what's new here?

Similar to interlock protocol (4, Interesting)

dmiller (581) | more than 9 years ago | (#11749638)

This is a little like the interlock protocol [ecn.ab.ca] , without the public-key cryptography. But this instance has the serious disadvantage that the server side must know the user's unencrypted password (or equivalent) to play the game. That is a very bad thing - it has been empirically demonstrated that users will resue their passwords, so any authentication database that keeps them in the clear is a high-value target for attackers.

BTW You are quite safe from MITM attacks when using SSH if you use ssh protocol 2 and public key authentication. The public key signature checks are bound to the results of the Diffie-Hellman key exchange that occurs at the start of the protocol. In the case of a MITM, these DH results will be different for the client->MITM and the MITM->server legs, so the real server will refuse to accept the signature that the client presented to the MITM and the authentication will fail.

This method is flawed (1, Interesting)

Anonymous Coward | more than 9 years ago | (#11749659)

This proposed scheme does nothing to prevent a man in the middle attack. For example, if a person is trying to log in to a server, they would wait for the server to prove it knows their password before actually sending the password. But the man in the middle attaker could obviously just start a login attempt at the real server to get the appropriate hash of the user's password. But since anyone can get this hash, where is the security?

My second Rant of the Day (3, Interesting)

TechyImmigrant (175943) | more than 9 years ago | (#11749671)

Mutual authentication sounds safe and warm. Alice know Bob is at the other end Bob knows Alice is at the other end.

However this is the situation after you have performed the mutual authentication, not before. In all protocols I have seen, this takes place in some order. In order for Alice to authenticate Bob's identity and the other way around, with both exchanges bound together (so differentiating from bilateral authentication), Either Alice or Bob has to first reveal their identity so it can be authenticated. This includes the proposed scheme.

This asks the question "Who goes first". Usually the protocol forces this issue and leaves one side or the other in the disavantageous position of identifying themselves first. This is analagous to the gatekeeper shouting "Halt! Who goes there?" to someone trying to enter. The person trying to enter is forced to go first and reveal themselves.

I may not want to reveal my identity to anyone, especially when it comes to say, wandering around in public with a wireless device. All sorts of tracking mechanisms become possible.

What we want is a "Who goes first protocol" so I can enforce my own policy on revealing my identity. If someone wants to sell to me, they had better go first. If I'm trying to get through a door, the building owner can reasonably expect me to go first. There are plenty of situations where a network may want to only reveal its identity to people who are allowed to know its identity, and noone else.

We already have the algorithms, but the protocols are stuck in the mud and prevent us from moving forward with security that offers more than what SSL gives us.

redundant and over-simplified (0, Redundant)

smakx (861510) | more than 9 years ago | (#11749682)

This article looks like the paper you would find on your desk the first day of 'security 101' class. As others have stated, nothing new is offered here, the conceptual model presented is not detailed yet flawed none the less, and the font size is the icing on the cake of annoyance.

Re:redundant and over-simplified (1)

izomiac (815208) | more than 9 years ago | (#11749856)

No kidding. Come to think of it, didn't he just describe a variation of Diffie-Hellman key exchange? And wasn't that ARP cache poisoning that he was describing with "It is not known how to protect against routing based stealth attacks. In fact, it has been shown in a recent publication that one cannot eradicate such attacks without introducing other vulnerabilities in the system."? Come to think of it, isn't there a program called anti-spoof [killprog.com] which does protect against this type of attack?

I... can't keep. Reading. (5, Funny)

StikyPad (445176) | more than 9 years ago | (#11749684)

By then, it may be too late, as in the meantime, the attacker may collect and even modify information that was not intended for him.

Damnit, Bones I, can't figure out how to, place commas in, my, sentences I know they, should go somewhere I'm. Just not sure where.

Secure Remote Password (5, Informative)

Gollum (35049) | more than 9 years ago | (#11749777)

... has solved this problem more than 6 years ago. And it does not require the password to be stored in clear-text by the server. (although, "with a little thought", according to the article, neither does this scheme. BAH! Proof is left as an excercise for the reader)

Stick with something that has been rigorously reviewed, and proven over a period of time. And something that can be explained simply, in terms of the actual technology, rather than resorting to pathetic analogies that do not explain anything!

SRP [stanford.edu]

in other news... (0)

Anonymous Coward | more than 9 years ago | (#11749836)

Microsoft files patent application for delayed password protection. Company then decided not allow anyone to use this patent and support bill gates plan to end use of passwords with biometrics.

This approach works in theory but... (2, Interesting)

Spy der Mann (805235) | more than 9 years ago | (#11749849)

the problem here is that a webpage is not data but also program (i.e. javascript).

Alice could log in to the fake bank, and not realize that instead of doing the magic password trick, she's sending her password in plain text. Why? Because at the moment, the password encryption is (putting SSL aside) implemented by javascript!

To be safe, a key encryption algorithm would need an established software running it (in this case, the web browser).

This means:

a) having a W3-approved algorithm to be implemented in browsers, or
b) Having downloaded specific software by the bank (i.e. bankOnline browser(TM) or something).

Actually Pretty Vulnerable (5, Informative)

Effugas (2378) | more than 9 years ago | (#11749955)

So I actually got this sent to me this morning, accompanied with some nice snarkiness about "known plaintext handouts".

http://www.eurekalert.org/pub_releases/2005-02/a af t-ncs021405.php

Hmm. It's basically Kerberos, except totally broken.

So we don't actually know how this protocol works, but the description at the above link is vastly more coherent. (Anything with "magic envelope" and "this is a metaphor" really shouldn't be taken as a protocol specification.)

===
CUSTOMER: Bank, I will send you some information that is encrypted. You can only decrypt it if you know my password. If you don't know the password, you could of course try all possible passwords (although that is a lot of work!), but you would never know from my message if you picked the right one. Once you have decrypted the message, I want you to send it to me. If it is correctly decrypted, I will know that you know my password already. Once I know that you know my password, I will send it to you so that you can verify that I also know it. Of course, if I am lying about my identity and don't know the password in the first place, then I will not learn anything about the password from your message, so it is safe in both directions.
===

It's also wildly exploitable. Here's how:

First of all, password brute forcing? Alot of work? Only if there's no way to execute an offline attack, i.e. you can run attempts as fast as your own computer can calculate them. What we need is an offline attack -- something that lets us try to try as many attempts as possible. The most important thing is verifiability -- we need to know when we guessed the actual password.

Can we possibly verify our guess? Well, Alice sends the bank some random data, which is dutifully returned to Eve. Eve sniffs this traffic, and now has a very simple task:

Guess all possible passwords the bank could have used to decrypt the password. When the content from Alice, decrypted with the guess, equals what came back from the Bank, Eve has found the password.

But then there's Eve's friend Mallory, who thinks Eve isn't ambitious enough and wants to steal anyone's password at the bank, not just Alice's. Suppose Bob has angered her somehow. Mallory can't sniff Bob's traffic, but then, she doesn't actually need to. Mallory can simply blindly provide some arbitrary data to the bank. It's garbage going out, but even garbage will decrypt into something. Unless the bank specifically has users provide some known plaintext in the outgoing data, it's going to "decrypt" that noise, using the password, into more noise.

Once again, outgoing data + bank password = incoming data. Mallory gets to do offline attacks too -- but against any user she wants.

Of course, the bank *could* put some sort of verifier in the message that Alice sends to it. But then Eve has an even easier time guessing passwords, since she just tries random passwords until the verifier is unveiled. No need to sniff the traffic back from the Bank (which is actually significant -- it means Mallory could firewall off the bank and still successfully participate in the auth protocol, with no way for the bank to find out.)

Anyway, long story short, broken. Really, really broken.

--Dan

Re:Actually Pretty Vulnerable (1)

Too Much Noise (755847) | more than 9 years ago | (#11750821)

Hmm. It's basically Kerberos, except totally broken.

My thoughts exactly - I was hoping to see more details on how it is different in a better way from Kerberos, but there's nothing (well, except "patent pending" which is hardly an improvement)

(Anything with "magic envelope" and "this is a metaphor" really shouldn't be taken as a protocol specification.)

Indeed. Maybe it was taken from the patent application? (can't tell, as there's nothing on uspto.gov so far)

easier to prevent man in the middle for ssh? (1)

planckscale (579258) | more than 9 years ago | (#11750128)

I'm a novice ssh user, and I'm a little unclear on man in the middle and if this carbon-copy technique will benefit? For example, my debian box got a new dhcp address after being powered off from a power outage, I ssh'd into it and Putty alerted me that it had a new signature (I assumed because of the new IP address). Will this technique benefit me by creating a carbon copy in addition to looking at the signature before I log in? It's probably my own fault because I never created and shared my own keys; I recall something about creating my own key, then entering that key into Putty, but it's escaped me. Does anyone have a good easy procedure to run if I ever get a notification that my hash signature has changed? A little extra protection sounds good especially if I'm connecting outside the confines of my LAN.

please help me understand (0)

Anonymous Coward | more than 9 years ago | (#11750144)

Hello,

I came across this posting and thought it was very interesting. I have a question about it though (I'm not a security expert so please forgive my ignorance if the answer escapes me).

It seems that an intruder can still impersonate the bank if he carefully selects the numbers. If he can correctly select a set of numbers such that they add up to zero, then Alice will believe he is the bank. So it seems the problem is selecting a set of zero-summed numbers, right?
What if the intruder were to select all 0's in every position of the "letter" except one, the last column? In the last column, the intruder places a 1 in the "top" position and sends the letter back. If the last digit is a 1, then the set of numbers (0+0+0+...+0+0) will not include the 1 and they will sum to 0 implying that this is the bank. Alice will willingly give her password away then, correct?. However, if the last digit is a 0, then Alice does not give her password, in which case the intruder can place a 1 in the "bottom" position and send the letter back. This time, Alice will not include the 1 in the top position and the set of numbers will sum to 0, making Alice believe the intruder is the bank.

Does that all seem to make sense? Where does my understanding depart from the truth?

Your help appreciated,
Kane

NAK (0)

Anonymous Coward | more than 8 years ago | (#11750225)

The proposed solution does not really differ from exchanging hashes of challenges and preshared secrets. Further, the article is badly written; e.g. it explains (or tries to explain) how a standard denial of service attacks requires the attacker to establish a very large number of connections to the victim even though this is totally irrelevant to MITM attacks discussed throughout the reminder of the article. Author confuses SSH with SSL/TLS (on purpose?) then goes on to say that MITM attacks can be used to [...] disrupt key exchange operations. I don't understand how authenticated Diffie-Hellman key agreement or SSL/TLS pre-master secrets fail to deliver key exchanges in this context. Anyone?

I RTFA and I'm not impressed (2, Insightful)

elronxenu (117773) | more than 8 years ago | (#11750324)

I don't know much about crypto but this paper strikes me as both original and insightful - the insightful parts are not original, and the original parts are not insightful.

First of all, we already have protection in protocols such as SSH and SSL against man-in-the-middle attacks. Thus, the paper's whole reason for existence disappears.

Secondly, the security of this "masking" technique depends upon the randomness of the numbers chosen by the server (and, by implication, any man-in-the-middle). I could send a packet containing all zeroes and it would guarantee to sum to zero after applying any mask at all. How does the receiver judge whether the numbers passed are sufficiently random?

Emails from the dead (1)

bolix (201977) | more than 8 years ago | (#11750454)

Before i rtfa, i thought this had links to the MS UndeadTAPI "PASSPORT for the beyond" i.e. a triggered email discloses your passwords in order to circumvent your family having to sue for disclosure. Next up in UndeadTAPI is auto-distruct pr0n (in XML).

"Computers" is possessive!! (-1, Troll)

Anonymous Coward | more than 8 years ago | (#11750510)

You wrote "Delayed Password Disclosure can validate a computers authenticity". HELLO?! Give me a break! "Computers" is possessive and should be spelled "computer's".

Held back. Repeating third grade.

Shout it from the rooftops! (1)

phliar (87116) | more than 8 years ago | (#11750644)

I guess his Mom never told him it was rude to shout, or to use MS-Word for editing HTML.

Proof of MITM attacks on HTTP/HTML (0)

Anonymous Coward | more than 9 years ago | (#11750790)

You know you're a victim of a MITM attack, if

a. Font size dramatically increased
b. Article content turned into nonsense
c. Both
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?