One of the more popular security builds in recent memory is USB password vaults. These small thumb drive-sized devices hold all the passwords you have to deal with, and are locked behind a authentication code on the drive itself. For their Hackaday Prize entry, [Miguel] and [Noel] asked how inexpensively one of these devices could be made. The answer, coming in the form of their Memtype project, is very inexpensively.
The Memtype project is based on the cheapest and most simplistic USB implementation on the planet. It’s built around an ATtiny85 and V-USB‘s software only implementation of a USB keyboard, requiring only a few resistors and diode in addition to the ‘tiny85 itself.
The device can only be unlocked with a four-digit pin, input through the clever use of a small SMD joystick. After inputting the correct code, the Memtype grants the user access to all the stored passwords. As far as security goes, [Miguel] and [Noel] have implemented NOEKEON in assembly, however it should be noted that all security is weaker than a pipe wrench. For managing the passwords, [Miguel] and [Noel] built a small, simple GUI app to set the PIN and write credentials to the device.
[Miguel] and [Noel] already have a demo video up for the Memtype, you can check that out below.
Continue reading “Hackaday Prize Entry: A Very Small Password Keeper”
[Matikas] apparently forgets to lock the screen on his computer when he gets up to grab a coffee. And he apparently works with a bunch of sharks: “If you don’t [lock it], one of your colleagues will send email to the whole company that you invite them to get some beer (on your bill, of course).” Not saying we haven’t done similar, mind you. Anyway, forgetting to lock your screen in an office environment is serious business.
So [Matikas] built a great system that remotely types the keystrokes to lock his screen, or unlock it with his password. An off-the-shelf 433 MHz keyfob is connected to an Arduino micro that simulates a keyboard attached to his computer. It’s a simple system, but it’s a great effect. (See the video demo, below.)
Continue reading “Coolest, but Least Secure, Security Device”
This “security” is so outrageous we had to look for hidden cameras to make sure we’re not being pranked. We don’t want to ruin the face-palming realization for you, so before clicking past the break look closely at the image above and see if you can spot the exploit. It’s plain as day but might take a second to dawn on you.
The exploit was published on [Mark C.’s] Twitter feed after waiting a couple of weeks to hear back from TP-LINK about the discovery. They didn’t respond so he went public with the info.
Continue reading “TP-LINK’s WiFi Defaults to Worst Unique Passwords Ever”
Passwords are terrible. The usual requirements of a number, capital letter, or punctuation mark force users to create unmemorable passwords, leading to post-it notes; the techniques that were supposed to make passwords more secure actually make us less secure, and yes, there is an xkcd for it.
[Randall Munroe] did offer us a solution: a Correct Horse Battery Staple. By memorizing a long phrase, a greater number of bits are more easily encoded in a user’s memory, making a password much harder to crack. ‘Correct Horse Battery Staple’ only provides a 44-bit password, though, and researchers at the University of Southern California have a better solution: prose and poetry. Just imagine what a man from Nantucket will do to a battery staple.
In their paper, the researchers set out to create random, memorable 60-bit passwords in an English word sequence. First, they created an xkcd password generator with a 2048-word dictionary to create passwords such as ‘photo bros nan plain’ and ’embarrass debating gaskell jennie’. This produced the results you would expect from a webcomic. The best ‘alternative’ result was found when creating poetry: passwords like “Sophisticated potentates / misrepresenting Emirates” and “The supervisor notified / the transportation nationwide” produced a 60-bit password that was at least as memorable as the xkcd method.
Image credit xkcd
[HD Moore] recently posted an article on Rapid 7’s blog about an interesting security problem. They’ve been doing some research into the security of automated tank gauges (ATGs). These devices are used at gas stations and perform various functions including monitoring fuel levels, tracking deliveries, or raising alarms. [Moore] says that ATGs are used at nearly every fueling station in the United States, but they are also used internationally. It turns out these things are often not secured properly.
Many ATG’s have a built-in serial port for programming and monitoring. Some systems also have a TCP/IP card, or even a serial to TCP/IP adapter. These cards allow technicians to monitor the system remotely. The most common TCP port used in these systems is port 10001. Some of these systems have the ability to be password protected, but Rapid 7’s findings indicate that many of them are left wide open.
The vulnerability was initial reported to Rapid 7 by [Jack Chadowitz]. He discovered the problem due to his work within the industry and developed his own web portal to help people test their own systems. [Jack] approached Rapid 7 for assistance in investigating the issue on a much larger scale.
Rapid 7 then scanned every IPv4 address looking for systems with an open port 10001. Each live system discovered was then sent a “Get In-Tank Inventory Report” request. Any system vulnerable to attack would respond with the station name, address, number of tanks, and fuel types. The scan found approximately 5,800 systems online with no password set. Over 5,300 of these stations are in the United States.
Rapid 7 believes that attackers may be able to perform such functions as to reconfigure alarm thresholds, reset the system, or otherwise disrupt operation of the fuel tank. An attacker might be able to simulate false conditions that would shut down the fuel tank, making it unavailable for use. Rapid 7 does not believe this vulnerability is actively being exploited in the wild, but they caution that it would be difficult to tell the difference between an attack and a system failure. They recommend companies hide their systems behind a VPN for an additional layer of security.
With all of the various web applications we use nowadays, it can be daunting to remember all of those passwords. Many people turn to password management software to help with this. Rather than remembering 20 passwords, you can store them all in a (presumably) secure database that’s protected by a single strong password. It’s a good idea in theory, but only if the software is actually secure. [Matteo] was recently poking around an Android password management software and made some disturbing discoveries.
The app claimed to be using DES encryption, but [Matteo] wanted to put this claim to the test. He first decompiled the app to get a look at the code. The developer used some kind of code obfuscation software but it really didn’t help very much. [Matteo] first located the password decryption routine.
He first noticed that the software was using DES in ECB mode, which has known issues and really shouldn’t be used for this type of thing. Second, the software simply uses an eight digit PIN as the encryption key. This only gives up to 100 million possible combinations. It may sound like a lot, but to a computer that’s nothing. The third problem was that if the PIN is less than eight characters, the same digits are always padded to the end to fill in the blanks. Since most people tend to use four digit pins, this can possibly lower the total number of combinations to just ten thousand.
As if that wasn’t bad enough, it actually gets worse. [Matteo] found a function that actually stores the PIN in a plain text file upon generation. When it comes time to decrypt a password, the application will check the PIN you enter with the one stored in the plain-text file. So really, you don’t have to crack the encryption at all. You can simply open the file and reveal the PIN.
[Matteo] doesn’t name the specific app he was testing, but he did say in the Reddit thread that the developer was supposedly pushing out a patch to fix these issues. Regardless, it goes to show that before choosing a password manager you should really do some research and make sure the developer can be trusted, lest your secrets fall into the wrongs hands.
In one month the Mooltipass offline password keeper project will be one year old.
We hope that our twice a month Developed on Hackaday series posts allowed our dear readers to see what are the steps involved in a device’s life, going from idea to prototype to crowdfunding-ready product. The Mooltipass is the fruit of a unique world-wide collaboration around open source, developed by and for security minded people who (for most of them) never saw each other. Relating our progress here enabled us to benefit from our readers’ feedback and make sure that we didn’t miss important wanted features. Contrary to other campaigns that we often debunk on Hackaday, we preferred to wait until we had a beta-tester approved device to move to the crowdfunding stage. Our geekiest readers will therefore find the launch date embedded in this post, other may want to subscribe to our official Google group to stay updated.