Hello. I'm one of the co-authors of the workshop paper that inspired this article. I say "inspired" because the article is completely misleading.
First off, the paper was a position paper. It was primarily speculation about how we could do authentication in the future. The idea behind it was that humans are bad at remembering very specific facts but are very good at remembering stories - narratives. What would it mean to authenticate using stories? Think about how you'd verify the identity of a friend communicating via text message from an unknown phone number or account. Make a computer do that.
And yes, fully developed such a system would be AI-complete. But I think there are lesser incarnations that might be usable and secure. But that is just educated speculation on my part.
Now the paper did present a simple example of how you could do something kinda-narrative-like using text adventures (yes, think Zork). Such a system isn't discussed in more detail because there are many usability challenges. But it can be done. Carson Brown got his Master's thesis in fact by by building such a system. (Yes, I was his advisor.)
If anyone wants to build a PAM module based on Inform 7 drop me a line. Could be fun! But it won't be practical.
You're being unfair to the Jarlsberg developers. "not vulnerable to typical buffer and integer overflow problems" is not the same as not vulnerable to *any* such problems. I agree they could be more specific, but it is true that you can't just run off the end of an array in Python like you can in C.
The bug report you refer to is about a flaw in the Python runtime environment, which is in fact a C program, and so is vulnerable to all the same problems as other C programs. To exploit this you have to give Python weird input. To corrupt memory in C, however, you just use regular language features, e.g., increment a pointer.
But anyway, spending your time looking for buffer and integer overflows in web applications is like looking to fix holes in the walls of a house where a tree has destroyed the roof - there are much bigger problems to worry about. Jarlsberg and WebGoat nicely illustrate this.
But what about every URL on the web? ObPwd isn't limited to songs, it can process anything web-accessible - images, HTML, PDF, whatever. Is that a big enough dictionary for you?:-)
>Some nanotech shouldn't be disassembled, and we should know how to make it that way.
That is only true if we depend on static structures. If nanomachines are dynamically maintaining a structure, it should be possible to have it be both extremely strong and degradable.
Nanotechnology is probably only feasible through the use of self-reproducing (or mutually-reproducing) machines. For such machines to be at all safe, we'll have to create entire "ecosystems" of such machines such that the actions of any one machine can be countered by another. (Why not rely on pure programmatic control? Well, how would we respond to software flaws?)
This may mean that we'll need the equivalent of tigers (predators) and dung beetles (scavengers) in our nanotechnological world, believe it or not. At the very least, we'll need such processes just to control "benign" devices that have been released into novel environments (think rabbits in Australia).
Unfortunately, in this context security flaws and malicious code could take on a whole new dimension. I just hope we figure out how to secure the Internet before we develop self-reproducing nanomachines.
Phages are viruses that attack bacteria, not the cells of our body. The "old Soviet research" is an alternative to antibiotics, not a type of cancer therapy.
This startup is using a naturally-occuring virus to kill cells with compromised anti-virus defenses. It just so happens that many cancer cells are so compromised.
Neat work! But definitely not the same.
--Anil
ccr - an earlier peer-to-peer MUD
on
P2P Roaming Chat
·
· Score: 2, Interesting
I'm afraid that Brendenland is definitely not the earliest peer-to-peer MUD. David Ackley has been working for many years on ccr, a system where individuals create and interconnect independent MUD-like worlds. One of the most important questions ccr addresses is the issue of security: when you are visiting another person's world, what should that other person be able to do to you? Also, ccr addresses the issue of hacked clients through code signing and chains of trust.
Slashdot Mirror
Hello. I'm one of the co-authors of the workshop paper that inspired this article. I say "inspired" because the article is completely misleading.
First off, the paper was a position paper. It was primarily speculation about how we could do authentication in the future. The idea behind it was that humans are bad at remembering very specific facts but are very good at remembering stories - narratives. What would it mean to authenticate using stories? Think about how you'd verify the identity of a friend communicating via text message from an unknown phone number or account. Make a computer do that.
And yes, fully developed such a system would be AI-complete. But I think there are lesser incarnations that might be usable and secure. But that is just educated speculation on my part.
Now the paper did present a simple example of how you could do something kinda-narrative-like using text adventures (yes, think Zork). Such a system isn't discussed in more detail because there are many usability challenges. But it can be done. Carson Brown got his Master's thesis in fact by by building such a system. (Yes, I was his advisor.)
If anyone wants to build a PAM module based on Inform 7 drop me a line. Could be fun! But it won't be practical.
If you want to learn more, the paper is "Towards narrative authentication, or, against boring authentication.". The workshop in question is the New Security Paradigms Workshop.
And in case you were wondering, none of us are doing any follow-up work on this right now. But I'm always open to collaboration opportunities. :-)
--Anil Somayaji
You're being unfair to the Jarlsberg developers. "not vulnerable to typical buffer and integer overflow problems" is not the same as not vulnerable to *any* such problems. I agree they could be more specific, but it is true that you can't just run off the end of an array in Python like you can in C.
The bug report you refer to is about a flaw in the Python runtime environment, which is in fact a C program, and so is vulnerable to all the same problems as other C programs. To exploit this you have to give Python weird input. To corrupt memory in C, however, you just use regular language features, e.g., increment a pointer.
But anyway, spending your time looking for buffer and integer overflows in web applications is like looking to fix holes in the walls of a house where a tree has destroyed the roof - there are much bigger problems to worry about. Jarlsberg and WebGoat nicely illustrate this.
But what about every URL on the web? ObPwd isn't limited to songs, it can process anything web-accessible - images, HTML, PDF, whatever. Is that a big enough dictionary for you? :-)
>Some nanotech shouldn't be disassembled, and we should know how to make it that way.
That is only true if we depend on static structures. If nanomachines are dynamically maintaining a structure, it should be possible to have it be both extremely strong and degradable.
Nanotechnology is probably only feasible through the use of self-reproducing (or mutually-reproducing) machines. For such machines to be at all safe, we'll have to create entire "ecosystems" of such machines such that the actions of any one machine can be countered by another. (Why not rely on pure programmatic control? Well, how would we respond to software flaws?)
This may mean that we'll need the equivalent of tigers (predators) and dung beetles
(scavengers) in our nanotechnological world, believe it or not. At the very least, we'll need such processes just to control "benign" devices that have been released into novel environments (think rabbits in Australia).
Unfortunately, in this context security flaws and malicious code could take on a whole new dimension. I just hope we figure out how to secure the Internet before we develop self-reproducing nanomachines.
Phages are viruses that attack bacteria, not the cells of our body. The "old Soviet research" is an alternative to antibiotics, not a type of cancer therapy.
This startup is using a naturally-occuring virus to kill cells with compromised anti-virus defenses. It just so happens that many cancer cells are so compromised.
Neat work! But definitely not the same.
--Anil
I'm afraid that Brendenland is definitely not the earliest peer-to-peer MUD. David Ackley has been working for many years on ccr, a system where individuals create and interconnect independent MUD-like worlds. One of the most important questions ccr addresses is the issue of security: when you are visiting another person's world, what should that other person be able to do to you? Also, ccr addresses the issue of hacked clients through code signing and chains of trust.
If you are curious about ccr and Dave's ideas, check out his home page and ccr's central keyserver.
--Anil