Slashdot Mirror
Scientists Release Working Prototype Of CAPTCHA-Based Password Assistant
An anonymous reader writes "Last year Slashdot ran a story on scientists from the Max-Planck-Institute for Physics of Complex Systems in Dresden, Germany developing a novel method to improve password security. A strong long password is split in two parts; the first part is memorized by a human, and the second part is stored as a CAPTCHA-like image of a chaotic lattice system. Today, after a year of work, the same group at Max Planck Institute released a working prototype online, where everybody can try this technology to encrypt files (Java plugin required)."
Not sure this is any better. If someone can guess the password, they can read the captcha. That is, unless the captcha is somehow stored on the local machine, which makes the file inaccessible except from that terminal.
Mark Anthony Collins
Rather than attempting to personally evaluate the paper, not being an expert in this area, it'd be interesting if a third party has done some analysis, even preliminarily, on the system, so we can rely on more than the authors' own views. The paper itself was published in a somewhat strange venue for a new cryptosystem, Europhysics Letters, which isn't really a problem, but doesn't provide strong assurance that cryptography experts have vetted it, either (but perhaps they have elsewhere?).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
This requires self-signed applet with full privileges so by using this new security solution I will put my computer at risk. Isn't that great? I would have expected that people working in the security domain would not have the "I don't bother about actual rights I need so let us request full access" attitude.
WARNING
My java said that the code was not signed. It could be swapped or faked. Don't run it unless it is signed and verified properly. It also gains full acess to your computer... so don't run it until it is restricted.
Plouf - we need these permissions in order to read the files :-)
As far as self-signed goes - we did not want to spend $500 on a chunk of bytes :-) Please trust us :-))
Konstantin
So it has come to this.
https://xkcd.com/936/
Shoes for Industry. Shoes for the Dead.
Too bad it require java support. I removed it since it's security risk overweight its benefit
A security researcher asking people to blindly trust strangers........
we need these permissions in order to read the files :-)
There are several mechanisms to upload files over HTTP without requiring local execution privileges. Why use this unnecessarily intrusive method?
Please trust us :-))
You're a security researcher?
Absolutely - I couldn't believe the irony of this great security solution requesting full access to my machine with a self-signed certificate. I wonder if this actually a psychology experiment to show that even when people are thinking about security that they're still willing to give up the keys to the kingdom as long as you ask nicely and state that you're a "security researcher".
Overuse of smileys detected... God damnit, wie alt seid ihr, 16?
What time is it/will be over there? Check with my iPhone app!
A security researcher asking people to blindly trust strangers........
IMO they really aren't. As it is uploaded unobfusacated and anyone can download it. It then takes 2 seconds to drop it in to the one of many java decompilers and you can read it yourself.
Who can blame them for not spending a couple of hundred dollars on a sining cert? I can't for a proof of concept.
In reality, something signed by Verisign isn't really any more 'secure' than a self-signed applet.
Besides, he's working on one little security feature. Why should he implement things that are not directly relevant to what he is researching?
Highly suspicious!!! I have just run this. Firstly the site appears to be Russian! Secondly I gave it full access to my computer! Now I don't know what I have compromised. Help ne slashdot, why did you publish this tripe?
It seems like all this would do is just decrease the brute force speed since you would have to do image analysis (assuming you could write a decent CAPTCHA solver). How would this be different than passing a password through an algorithm 1000’s of times? Also it seems like it might decrease password security. Depending on what is known about the encrypted data, an attacker may not have any way to check if the password is correct. With the CAPTCHA, I would think it would be quite easy to detect the characters that are out of the norm of randomness even if you can’t tell the letters and pass it to a human or deeper scan. That is unless there are false positive CAPTCHA outputs?
Folks - thank you for all the comments.
As far as applet goes - this is a demo prototype for the scientific community to evaluate our algorithm.
Signing the applet would require formalities + money but would not actually add much security we could put a trojan into a signed applet too.
We are planning to release our source code soon anyway.
Our web site and applet are not Google or Facebook :-) Please pardon our dust :-)
We are looking forward to receiving more comments on the algorithm and paper.
Thank you,
Max Planck group
These stories seem to pop up every week about how we have a new system that is better than a regular password. You can't get better than a regular password because the weakest link in the whole password process is the human. Make the authentication process any more complex and the human becomes an even weaker link. The other big miss that none of these stories never seem to cover (esp biometrics) is that the great strength of a password is its portability. If I need someone to do something on my behalf I can tell them the password and they can do it, and it gets done. This may sound like a weakness on the surface, but the alternative non-portable method would mean all those things wouldn't otherwise have been done, and ultimately systems are designed to do things. Therefore, too strong an authentication makes the overall system less effective. Security is about balance. You can't build a house without doors and windows, and I think the regular old password is the best balance you'll ever get to authentication. Why waste energy trying to build a better mousetrap?
Slashdot comments usually contain at least a few insightful comments, but so far people have been going for wisecracks and low-hanging fruit.
Yes, using a self-signed certificate in a security product is stupid. Yes, trusting physicists to come up with a good encryption scheme is like hiring a plumber to do heart bypass surgery (I am a physicist). But those are boring criticisms. A more interesting question: is the basic idea actually any good?
If you play with it, it looks like it boils down to using a short easy password to generate a chaotic bit pattern; this bit pattern is XORed against a Captcha image. The result is easy for humans to read. If you try to decrypt with the wrong password, you get a different chaotic bit pattern that can't be read. But a computer has to do a lot of work to figure out if each bit pattern contains readable text or not.
The goal here is not to increase the entropy of the password, or to use an asymmetric algorithm that's much easier to encode than decode. Instead, they're trying to make each decryption attempt require enough compute cycles that it's impractical to brute-force even a short password.
The obvious direct attack is to write a very good, very fast captcha detector. It doesn't actually have to be able to *read* the captcha at all: it just has to be able to filter out "obviously doesn't contain text" from "probably contains text", and present the likely candidates to a human for final analysis. Some sort of noisy edge detection algorithm might work well.
If you hate writing computer vision algorithms, a simple Mechanical Turk approach might also work. If you presented a full-screen grid of 100 candidate decryptions to a human, they could probably identify one that contains text in a couple of seconds. A single human should be able to complete an English dictionary attack in a day.
So you want it to work offline; that's commendable. But why not offer it as a downloadable, double-clickable jar so that it'll already have the needed capabilities?
There are too many oddities for me to try out the service, sorry.
1. The service isn't hosted on a .edu domain.
2. The about page makes a remarkably strong and vague claim for a group of scientists: "We are currently the strongest online encryption service available on the Internet."
3. The story was submitted anonymously rather than with a "full disclosure" warning.
4. There's no link on the web site to any supporting institutions, grants, or anything like that, even though the summary twice mentions the Max Planck Institute.
5. The unsigned software wants full access to my machine.
For all I know, this is an elaborate ruse to get a few poor saps to run untrusted code. I have nothing but the web site's word and the word of an anonymous commenter to go on balanced against the above weirdness, so I'm going to play it safe and move on.
As for you, "Konstantin," perhaps you're just a weird person, but there are way too many oddities for me to simply believe that you're the K. Kladko from the paper.
1. Your grammar and style are remarkably informal for an academic. You write like a teenager. /. comments about their work, or if they do their posts are highly informative (eg. The Bad Astronomer).
2. You use way too many smilies for a security researcher.
3. You sign your name while posting anonymously--just sign up for an account already.
4. You expect me to run untrusted code on my machine as a security researcher just because you say, "Please trust us". Seriously? Seriously? (It bears repeating.)
5. You're making lots of comments here. Usually scientists don't make any appearance on
My strong suspicion is that you're just rather young and naive and don't have enough supervision on this project. I'm not trying the software though.
It's in Java, and Java bytecode decompiles much more cleanly than, say, x86 bytecode compiled from C. Did you try decompiling it and reading the resulting source code? If not, why not?
I couldn't believe the irony of this great security solution requesting full access to my machine
No, full access to the files in your user account, not your entire machine. And that's only because unlike the Sugar, Mac OS X, and non-IE JavaScript sandboxes, Java has no concept of a file I/O capability limited to files chosen through a trusted file chooser dialog box.
with a self-signed certificate
APKs from unknown sources for Android are likewise self-signed, yet people install them. Heck, people install Windows applications developed by hobbyists even without a signature.
The service isn't hosted on a .edu domain.
As I understand it, only institutions in the United States qualify for a .edu domain. A British institution would be .ac.uk, etc.
The unsigned software wants full access to my machine.
Can you figure out how to express, in Java, a capability that applies only to those files chosen with a file chooser? And can you figure out how to make code signing certificates as affordable as SSL certificates? Do individuals (as opposed to corporations or LLCs) even qualify for such certificates?
I find the idea very interesting, but isn't it sad this approach wouldn't work on a text-based terminal (e.g. an ssh login)?
A security researcher asking people to blindly trust strangers........
IMO they really aren't. As it is uploaded unobfusacated and anyone can download it. It then takes 2 seconds to drop it in to the one of many java decompilers and you can read it yourself.
Who can blame them for not spending a couple of hundred dollars on a sining cert? I can't for a proof of concept.
If end users are expected to decompile the code and inspect it every time it downloads (or updates) then this isn't a solution for the +99% of internet users who don't know Java. As for me, I'd rather spend the little extra time typing in a second password without this CAPTCHA scheme and not decompiling & inspecting code.
I've just gotten three of them wrong in a row. Also, the input box doesn't appear to always capture the keyboard in Linux.
I thought the whole point of distributing software as source code (or in a form from which source code could be easily derived) was that it could be audited. If this auditing turns out to not in fact take place, then how does any program from any author prove itself trustworthy? A CA-signed certificate is not the answer because the CAs don't do this auditing either. OLPC Bitfrost and Mac OS X's sandbox get it right: the operating system provides trusted file choosers to authorize access to individual files and folders.
whois crpt.me results in:
At least, it is one of the authors and the address matches the Max Planck institute. I'm not sure whether a .me (Montenegro) domain requires proof of identity, though.
Avantslash: low-bandwidth mobile slashdot.
I got sick of getting them wrong all the time. I finally just downloaded a browser plug-in to do them for me.
The Official Site of 1337 Pwnage
My strong suspicion is that you're just rather young and naive and don't have enough supervision on this project.
That's a no-brainer on /.
I am anarch of all I survey.
A security researcher asking people to blindly trust strangers........
IMO they really aren't. As it is uploaded unobfusacated and anyone can download it. It then takes 2 seconds to drop it in to the one of many java decompilers and you can read it yourself.
Who can blame them for not spending a couple of hundred dollars on a sining cert? I can't for a proof of concept.
If end users are expected to decompile the code and inspect it every time it downloads (or updates) then this isn't a solution for the +99% of internet users who don't know Java. As for me, I'd rather spend the little extra time typing in a second password without this CAPTCHA scheme and not decompiling & inspecting code.
My point is that this is a proof of concept. For some reason people are irrationally flipping out (imo). When the fact is they could have distributed it in a desktop launchable (just the jar) form (requiring more user work(executing a command and or more complicated.. java != your friend) and people would never see any code signing issue. The fact is that to make it easier you get a warning since they don't want to shell out hundreds for a proof of concept. Can you blame them? My statement was more of a blanket that they aren't trying to hide anything. Since they chose to deliver it in the fashion they did everyone flipped out. As a java dev I see where they are coming from and wanted to make the point that they aren't doing anything fishy and could be easily checked on. Just logical.