Wiperless windshields in your future? Thanks, nanotech.
Topic: Technology
10:31 pm EST, Feb 24, 2008
The first layer protects from sun and repels water, the second layer features "nano-dust" to push dirt to the edges of the windshield and is activated by the third layer which senses the dirt, while the whole kit is powered by the fourth layer which conducts electricity to keep it going. The tech could be ready for mass production within 5 years, but there's already a working prototype in the Hidra concept car.
A team of Russian hackers have found a way to read the CAPTCHA with 35% accuracy. Let there be no mistake: the CAPTCHA that Yahoo! deploys is believed one of the most difficult CAPTCHA's to crack. It utilizes bended alpha numeric characters and other features you might expect from a strong CAPTCHA, and still it's easy to solve by humans.
Impressive Russian hackers... Only failing roughly 2 out of 3 tries. The Russian hackers went on to say:
The CAPTCHA has a vulnerability we'll discuss later. It's not necessary to achieve high degree of accuracy when designing automated recognition software. The accuracy of 15% is enough when attacker is able to run 100,000 tries per day, taking into the consideration the price of not automated recognition – one cent per one CAPTCHA.
Why can they get away with 100,000 tries per day?!?! That statement made me think that Yahoo's CAPTCHA sounds like a good candidate for the incremental delay anti-bruteforcing technique. In short, the incremental delay could decrease the number of successful attacks by delaying the response time from a failed automated attack.
After the first failed login attempt, for example, the response would be delayed by one second. After the second failed attempt, the response would be delayed by two seconds, and so on. A one-, two-, or even six-second delay is probably not going to bother a human user too seriously. Certainly he will find it less irritating than having to wait 30 minutes for his account to reactivate because he accidentally left his caps lock key on. On the other hand, an incrementing delay can completely defeat an automated tool being used for a brute force attack. Assuming the tool could normally make ten requests per second, the time it would take to make one thousand requests would jump from two minutes to five days. This pretty much renders the brute force attack tool useless.
If only to prevent Russian spammers from creating less bogus Yahoo email accounts to SPAM from; do you think incremental delay would help Yahoo?
When I wrote the ASP.NET book I pretty much lived in Reflector 24/7 to figure out all the gory implementation details. Back then it would have been great to be able to simply set breakpoints in some of the low level classes like HttpRuntime or modules.
Fortunately this is now possible, here's a quick walkthrough:
* Set up your Visual Studio to work with the new .NET symbols. Also have a look at the various symbol loading options you have. * Open an ASP.NET app * Set a breakpoint somewhere in your code (e.g. in a Page_Load) * Let the debugger hit the breakpoint * Open the call stack window and navigate up the stack, e.g. to HttpRuntime.ProcessRequest or Page.ProcessRequest * Set a breakpoint (use HttpRuntime.Init or the (c)ctor to step through the whole initialization process) * Right click the breakpoint, select location and check the "Allow the source code to be different from the original version" option. * Debug again. The debugger should now hit the breakpoint in the ASP.NET infrastructure class * Depending on how early in processing you set the breakpoint, you may have to recycle the AppDomain to start over. Simply make a change to web.config and save to trigger recycling.
This is a reminder for me to try again at getting ASP.NET Regex Validators to fail. I tried a few months ago while waiting at the airport for my connecting flight. Other than making the Regex.Match thread hang with backtracking I was unable to make the regex validator fail.
I was only poking around with Reflector before, but thanks to Dominick Baier for reminding me that I can now hook a debugger to the code I previously couldn't.
Created by Academy award nominated director Fredric Golding and presented by Fortify Software (www.fortify.com), The New Face of CyberCrime gives a face to the criminals' intent on hacking into your systems today. Who are they? How do they think? What makes them successful? You'll also hear candid interviews with many industry leaders and executives of large organizations taking steps against these attacks. Understand how they think about these threats and what they are doing about them throughout their companies.
“HACKERS, welcome! Here are detailed circuit diagrams of our products — modify them as you wish.”
The OSD is a versatile recorder. Using a memory card or a U.S.B. storage device, it saves copies of DVDs, VHS tapes and television programs from satellite receivers, cable boxes, TVs and any other device with standard video output.
Because the OSD saves the recordings in the popular compressed video format MPEG-4 (pronounced EM-peg), the programs can be watched on a host of devices, including iPods and smartphones. The OSD is for sale at Fry’s, Micro Center, J&R Electronics and other locations for about $230.
With AppJet, you write your entire app using JavaScript, including the server logic and database. This simplifies the process of building a web app, because it lets you do everything in just one language. JavaScript is easy to learn, but still pulls its weight for advanced uses. In fact, the AppJet site itself and the AppJet framework are written in server-side JavaScript.
The first thing I thought of when I saw this is a web hackers wet dream. A host and framework for creating javascript apps with easy hooks for storage and HTTP request/response objects.
Dominick Baier came up with a good idea to extend the HtmlEncode() and UrlEncode() methods to implement Microsoft's AntiXss version of these same methods.
Part of the research I've been doing on static analysis has included identifying sources of potential tainted data in ASP.NET and the source-sink connectivity. During analysis if a source passes through a sanitizer we don't flag a vulnerability. Even if that sanitizer is a worthless piece of shit. (Yes, I'm talking to you...people who like to use .* in your Regex validators) We already provide pre-built validators in the product I work on, but what if we could also reduce the number of unsafe ways data is used in a program. Which brings us back to Dominick's use of Extensions. Imagine if the user could use a "Secure" Label control or a "Secure" Databound Literal control that would automatically filter a XSS attack when the Text property is accessed. Of course you could achieve that type of functionality without Extensions but I thought it was an interesting use of the new language feature.
During normal operation or in Safe mode, your computer may play "Fur Elise" or "It's a Small, Small World" seemingly at random. This is an indication sent to the PC speaker from the computer's BIOS that the CPU fan is failing or has failed, or that the power supply voltages have drifted out of tolerance. This is a design feature of a detection circuit and system BIOSes developed by Award/Unicore from 1997 on.
"Fur Elise" would be much more pleasant than an error message or a droning beep. "It's a Small, Small World" on the other hand is straight annoying.
