Sorry for the Insecure Passwords…. NOT….

Oh brother, here we go again…

Creator of NIST Password Rules Apologizes

There is a common thread, ALWAYS, when discussing passwords, particularly length, complexity, value.

There are a couple of reasons this is generally all bunk and the author of NIST Special Publication 800-63. Appendix A, does not have that much to apologize for.

First, some truth.

The information about passwords in the NIST publication was already dated when it was published in 2003. The author, Bill Burr, does have to apologize for that.

But not much else.

Secondly, some fact.

The people, almost *always* complaining about password rules and looking for any excuse not to follow them are usually people who don’t understand the science and math surrounding them. While people can recognize obvious bad passwords, good ones are actually much harder to spot, because good passwords have one thing in common, they are complex combinatorically.

Bet you never heard that word before… more on Combinatorics later…

Next, an unfortunate but all too natural phenomena of iteration, evolution and progress.

Lastly, before the boring stuff, there is no such thing as a secure anything. Security is a state, which changes from time period to time period and evaluated based on prevailing threats with some measure of risk assessment for both the known… and unknown threats.

So, by definition, there are no permanently secure passwords (or permanently secure anything).

Given enough time, tools, power, situation, opportunity (and opportunity cost), vulnerabilities, a little luck and desire, everything is crackable.

With that in mind, any advice on secure passwords WILL only be valid for a certain period of time.

So there is absolutely no excuse in not following that advice, it doesn’t really matter how you feel about it or how lazy your fingers are, with the knowledge that it is going to change at some later date.

This phenomena is generally a result of changes in technology and more importantly changes in the prevailing tactics used to get around it.

For example, in the 1970’s when everyone is using birthdates as passwords, once attackers know this is common, they proceed trying passwords with birthdates. Next, people start using the recommendations in the NIST 800-63 publication (which is 1980’s circa advice, despite it being published in 2003). So the attackers now know the majority of sites use these recommendations… and adjust their method of attack to include the NIST 800-63 recommendations.

This is natural, there is nothing you can do about it.

This is iteration. Next, evolution…

Cracking passwords takes time, the harder a password is to crack, the more time it takes. Of course, if it takes 100,000 years to crack a given password… that is a good password, why? Because you are likely to be dead for 99,900 years by the time it gets cracked and your bank account is long gone.

However, computer power increases periodically, thus, the time to crack a passwords shrinks. In addition, sometimes weaknesses are found in password encryption algorithms and that further shortens the time to crack them. This is evolution, these things can’t be stopped.

Ok, so let’s bring this all home.

At the heart of this discussion for passwords is Combinatorics. In math, combinatorics is the science of “Countable Discreet Structures”. Put in English… the study of counting sets of thing used in combination (i.e. If I have 3 objects, an apple, an orange and a banana, how many ways can I order them as a list of three items [Apple,Orange,Banana], [Orange,Apple,Banana], [Orange,Banana,Apple]… etc.

As the set of things grows and the number of items in the list also grows, this increases entropy (in English, the number of combinations).

Thus, low entropy sets are easy to crack, high entropy sets (or longer lists with more things I can use in each place in the set), gets progressively harder to crack. At some point, it gets so hard, the set of objects and length of the list becomes at first, exponentially large and if I keep going increasing either or both, geometrically hard. Randomness adds to entropy, but reality is, passwords are not truly random (even when using online password managers that supposedly generate random passwords). Computers don’t have a “random” anything, scientifically speaking, computers are only “pseudo random”. Plainly, randomness in computers starts from a set of initial conditions and iterates through an algorithm which creates a progressive random sequence of numbers. Thus, if you know the initial conditions and the algorithm, you can calculate the sequence of numbers, despite the sequence being random.

This is the goal for picking relatively secure (although realistically, temporally secure passwords), pick exponentially or geometrically hard to crack passwords; passwords with high entropy.

So here is the kicker, this still isn’t good enough… why… search space. If my set of objects is known (which it is, keys available to me on a keyboard) this is part of the space of objects an attacker can search through, then the only mystery is the length of my string of characters in the password. To make matters worse, if an attacker knows the limits of what I can use for a password, for example, some websites only allow for letters and numbers, it tells the attacker how s/he can further narrow the possibilities of what my passwords could be. Knowing corporate policy on passwords is also useful and clearly, if nearly everyone is following the recommendations of NIST 800-63, the attacker has even more advantage.

So even geometrically complex passwords can have weaknesses based on policy, prevailing trends, technically imposed limitations and available pools of characters.

So this is why you hear people say “passwords are useless and irrelevant”. Of course, this is all hogwash. They are not useless, they are only useless if you set them once and never change them, once they become an immobile target, time is on the attackers side for all the outlined reasons, changes in computer power, some predictability in the search space and the fact that the password isn’t really random. Cries that passwords are dead, “long live passwords”, are merely the cries of lazy ignorant people with no insight into what makes for a good password, it is literally like someone shouting “fire” in a crowded theater… it’s irresponsible.

So the best strategy is…

  1. Understand passwords requirements (or authentication methods in general) are going to change over time.
  2. Follow the prevailing advice on authentication methods… and maybe add some personal flair so your methods aren’t exactly the same as everyone else’s.
  3. Pick passwords that have some amount of complexity (i.e. higher entropy).
  4. Follow this simple rule, using longer passwords means you can change your passwords less often, shorter passwords means you will have to change much more frequently. But as a rule, you must change them at some point, hopefully on a regular basis.
  5. Where you can, use 2-factor or multi-factor options.

What really seals the deal on decent passwords is 2-factor authentication (aka 2FA). You should still periodically change your passwords even with 2 factor, but with it, you have significant leeway on how often and when. If anything, 2FA should appeal to the laziest people.

Of course, this is a complex topic, authentication in general that is. There are many other discussions and arguments that can be made here surrounding it. Suffice it to say, this information above is not wrong, although it may be open to interpretation. That being said, it’s still, presently, sound advice.

Oh the Tangled Web…


Regarding security failings…

The long and the short… the vast majority of security failings fall into these general categories… both behavioral and technical.

  1. Slow, Bad or Non-existent Patch Cycle
  2. Poor CONFIGURATION decisions
  3. Installing to much software of debatable value (and forgetting about it).
  4. The required use of legacy systems with ZERO compensating controls
  5. Fire-and-forget mentality (i.e. long term complacency or laziness)
  6. Not knowing your limits, unwilling to accept limits, being too cheap or not having enough funding (which all has to do with heeding your local professionals, paying for some or living with centralized services which might not be as flexible [for similar reasons]).
  7. No situational awareness of the current network’s configuration or defenses, again, an assumption of defacto protection when there is generally near zero protection. This also falls under the category of assuming someone else is defending you (that always makes me smile because it’s just… soooo wrong…).
  8. Being unware that some of your habits/behaviors, for good or ill, contribute deeply to your susceptibility (poor passwords, never changing them, having accounts on every website or service under the sun with the same passwords, etc).
  9. The very wrong assumption that no one wants to hack your machine (hint: they couldn’t give a rats-*ss about you or your unimportant data [selfies, cat pictures, great American Novel, etc]… it’s the equipment they want access too, you are barely part of the equation).

In all cases… bad decisions, foolish assumptions and fatal mistakes.

Make noooo mistake on this… your devices are targets, mainly because they are a working piece of equipment built on a lot of risky decisions and false assumptions.

In the end, I would say, heed experts. But this is not enough, you have to be able to think a little too and live within your limits. Technology is not perfect… precisely because people are not perfect (scary thought eh?) So you have to assume all your technology can betray you at some point (and someone else’s as well); so it’s best not to have blind faith in your device’s ability to protect you if you are not also an active part of it’s defense.

Alternatives to FTP (or How I Stopped Worrying and Loved The SSH)

Forgive the Dr. Strangelove reference, but sometimes life around here is just as bizarre as the world of that movie.

With the final closing of the second of the 4 fatal protocols, namely FTP (and formerly Telnet, can you guess the 3rd & 4th?) Here is a quick meditation on how FTP is just no longer required and there is an AWESOME alternative… if you are just willing to open your mind a bit.

Since SSH provides three major features, encrypted communications, encrypted sign-in and built-in second factor authentication, what is there NOT to love about SSH?

The direct replacement for FTP via SSH is of course, SFTP. Certainly you can use SCP to, but for the moment, lets stick with SFTP as we are really talking about replacing FTP here. Also, this discussion focuses on Unix/Linux and even MacOS X. Windows on the other hand, is a separate story.

Your first response might be, “but allowing SFTP gives people implicit access to the SHELL”. I am sorry to tell you this… but horse-dinky. At least, horse-dinky for OpenSSH 4.9 and up (7.2 is the current stable release). Other SSHD server’s your mileage may vary.

A side note, as some will note, years ago, I said of OpenSSH, “…I wouldn’t give it to my worst enemy… well… maybe my worst enemy, but no one else.” Back in the day, OpenSSH was a total wreck, but after some soul searching… and the fact that the majority of the flaws came from one programmer and OpenSSH itself went full hog into auditing this guy’s code… it’s been pretty stable since.

Having said that, don’t download, compile and install SSHD on your own. Get it from a Package Manager or at least use one supported by whoever your vendor is. Why? Well, given OpenSSH’s track record and continued footprint around the world, it will always be under attack and you want to be sure your updates to it are automated and not have to think about it.

For SSHD implementations that do not have the correct feature set, there is “scponly”, https://github.com/scponly/scponly/wiki. But I wouldn’t recommend it if you can avoid it.

Ok, the meat… SSHD has two wonderful features that many people are not aware of.

  1. A flag called “ForceCommand”
  2. Pattern Matching and Conditional Processing in sshd_config

With these two features, you can limit users or groups to SFTP only and deny them access to the shell. A pro tip though, I would still also set the user’s account to “noshell” or “/bin/false” just for safe measure (see “man chsh” on your computer of choice for that). If you have other protocols enabled like… gack… telnet, rlogin, rsh or any other one that requires a user account but no shell access, then do this anyway. (btw, Friends don’t let friends deploy telnet, rlogin or rsh and if you do use them… shame on you…)

The totally cool part is, not only can you limit an individual user or group, the matching and conditional processing in sshd_config allows you to limit where they come from, what commands they use, Change their root and set a whole lot of SSH settings just for them.

Ok, here are a few examples… Let’s limit the user “bob” to SFTP only, in /etc/ssh/sshd_config (or wherever your SSHD config is located), I would append the following..

Match User bob
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no

In this example, conditional processing will match Bob’s username and execute the commands under the match statement. In this case, we Chroot to Bob’s “%h” (aka Home directory), so he can only save to his home folder. We also here, limit him to SFTP and we limit his ability to use SSH to forward himself around to other places or create tunnels. Literally, we tell SSHD, SFTP to this folder ONLY.

Let’s say Prof. Rob has students that need to submit homework assignments. Yes, Prof. Rob could use one account, a service account, for this… while this is very much like anonymous FTP, it is highly not recommended. Instead, we create a user for each student, student1 through student230 (it’s a big class). We create a group, “PHY222” and add all the users to this group.

Then we create a folder in Prof. Rob’s home (or anywhere else to be honest), called, “Phy222Homework”. Chown it to “chown rob:PHY222 Phy222Homework”, then Chmod it to “chmod u=rwx,g=rws,o-rwx Phy222Homework”. Finally, create folders under “Phy222Homework” named after the users.

Again, add to the bottom of /etc/ssh/sshd_config…

Match Group PHY222
ChrootDirectory /home/rob/Phy222Homework/%u
ForceCommand internal-sftp
AllowTcpForwarding no

Effectively, each user can place files only in his/her sub folder in Prof. Rob’s Phy222Homework folder and has no shell access.

You can do this as outlined, for letting people place webpages in folders under a webserver, skies the limit here.

Now…, do you want to turn it up to “11”.

SSH has built-in two factor authentication… sort of… but still, awesome despite it being “sort of”. SSHD allows the use of self-generated keys. Basically, you (or the admin for your server) generates a key and then places a checksum of the key in file named “authorized_keys” in the “.ssh” folder in your home directory. You can also place the key there so that you can use it to access other systems, but that is a post for another time. The key, can either have a password… or not.

As matter of policy, your keys should have passwords, I can’t stress that enough. I won’t even address having keys with no password here.

The beauty of a key with a password is this, when you type in the password to authenticate, it unlocks the key. The key, then becomes your password effectively. So when you log into an SSH server, the password used to unlock the key never travels across the network. This… is… huge… because there is now, no password moving across the network that can be captured and the key itself is never revealed because anything encrypted with it, is decrypted at the other end using the hash in the “authorized_keys” file or via a negotiated key using the hash as a key.

Which, I should mention, never never never ever, exchange a key or key-hash with a user via email or any other insecure method that could be intercepted. If you do, consider the key worthless. I would recommend that keys are either distributed over authenticated and encrypted channels or in person via a portable media (like a flash drive).

You can generate OpenSSH keys on a Unix/Linux/MacOS X systems with ssh-keygen (see the man pages) and on Windows PC’s using PuTTY’s puttygen.

The key thing to remember with “puttygen” is that it saves the hash (and key) in a PuTTY format. You must use the export menu option to export it to an OpenSSH recognized format. The hash, can be lifted from the main window. The output window visible when you generate a key contains the hash in a format that you can place directly into an “authorized_keys” file.

Always use SSH-2 or newer, prefer RSA over DSA when selecting a key and lastly, pick a decent key size. These days, 2048 for key size should be considered a minimum, however, 4069 or 8192 are better. The number, in case you were wondering, is a power of 2 (or a multiple of 512 or 1024, i.e. 1024 & 2048 divides evenly by both 512 or 1024; and represents the number of bits in the key.

You might think the larger the bit size, the slower your connection, this is not true. This is because, the key is only used to encrypt a session key and is used infrequently during the course of the connection, the session key itself is used for the majority of the connection. While the key size may effect the time for build up and teardown of the session, you probably won’t even notice that. So 8192, or 16K keys… not a problem. Larger key size will give your key more life as advances in computing power are prone to reduce the life span of encryption techniques. So don’t be chintzy with the key size.

Not Original, But, Still Kind of Cool…

To make a long story short, I ended up at one point, buying two little 3x3x3 LED cubes from Radio Shack. They were about $20 a piece. Ultimately, the point was to mount them on my Udoo Quads (http://www.udoo.org) and control them through the Serial comms port using a Python script. While I had some trouble porting over the code from the Arduino it was meant to run on, once I figured out what I was missing it was a snap.

I even asked Dave to look at it, he couldn’t figure it out either, the answer came to me in a flash of insight. The cube is a Charlieplex system, and I was confused about the order in which the pins controlling the LEDs were being set high and low. To both of us at the time, it made sense, setting them high, turns the LED’s on, setting the pins low would turn them off.

Turns out it was the opposite. What we both missed was that, when the pins are low, they are grounded. Thus, if you are putting in 5v at each end, you get nothing, ground the cathode end and the power flows…. and we both  missed that part, that the cathode was set high to “shut off” the LED’s.

Anyhow, I kept one of the cubes for other purposes. I wanted a cube in a different color so I sourced almost all the parts from eBay and assembled one from scratch in Blue 3mm LEDs with an Arduino prototyping shield. See the video below for the Cubes in action.

Aside from having a cool little 3x3x3 LED cube, I had a purpose for controlling them with the Udoo’s. At the moment, I use the Udoo’s mostly for experiments, while they are not doing anything in particular, they are running Litecoin crypto coin mining software. They really aren’t powerful enough to make any Litecoin worth having, BUT, when the mining software submits a hash, it takes the cube out of demo mode (cycling through all the patterns it has except for one special one) and then display’s the special one. Basically when a hash is submitted, the cube pulses itself.

The two Udoo’s the cubes are on, will never find a block or get much in the way of work hashes, but it is a neat conversation piece.

Holiday Cheer

I worked on this project last year. Electronics by me, wreath’s by my wife. We made two of them. We also make a pretty good team. Most of the parts by Adafruit… ahaha…

eWreath

eWreath with the LED’s off

Of course, it looks better with the lights on…

eWreath with the lights on

eWreath with the lights on

Basically, its a typical wire wreath (from Joann’s) with some extra wide gift ribbon hot-glued and wired up to the wreath wire. Inside is a strip of Adafruit Neopixels also wired up to the frame.

The Neopixels are driven by an Adafruit Trinket mounted in a project case. The colors can be programmed in code and they cycle. I was heading towards a more ambitious configuration where I’d use something that had WiFi or Bluetooth, so I could control it from a cell phone or tablet. I am saving that for Version 2. I’d upload a video, but the best one I have is larger then the max limit for uploading videos here. 🙁

The colors can be changed to suit the holiday since the Neopixel strip is RGB and you can program most colors. Next year we might put it out during Halloween with a nice Orange glow.

And that is one of the more interesting things. The Neopixels are quite bright. Seen the picture above, the brightness and color was turned down a bit because in full red it washed out the picture. I was hoping the ribbon would diffuse the LED’s… and it did somewhat, but the Neopixels are REALLY bright.

 

 

Forgive the rapid fire posts…

I took my independent blog offline… more or less, actually, GoDaddy took it offline… I had… technically… made the mistake of selecting a Windows environment for my hosted content. GoDaddy eventually turned over the Windows based hosting to Plesk. But even so, that was only for a year at the current rate I pay. After that, who knows.

So I set the Plesk stuff up… I wasn’t happy with it… I let the blog and site lapse as they turned it off. I saved the content, hoping to deploy it someplace else… I will eventually do that… but I kind of got distracted with other projects.

Of course, I skulk around the Element14.com community looking for pointers, tips and occasionally… parts for my electronics hobby.

Periodically they have these things called “Test Drives”. Basically you submit an application about what you plan on doing with the thing/stuff they are test driving and if you are chosen, then you get one of the things/stuff’s to test drive and do a write up. I was fortunate to have been selected for a Raspberry Pi 2 test drive; which was quite awesome. I wasn’t completely happy with the test drive though because I ran into some minor problems along the way with software, BUT, thankfully I learned a thing or two in the process. For example, I wanted to run performance tests on it. While I did that, I ran into a dead end at the Linpack series.

However, this lead me to another test suite, that I use regularly now for testing these little small board computers.

Today, I discovered they have another road test. This time with what looks like an introductory course in Microcontrollers and C. Of course, one of the things you have to do in the application is list some of your projects… with my personal blog offline… that kind of messes me up a bit with links to project content… so I am posting them here in rapid fire progression so I have a place to link to them for the application.

While I think I am probably a good candidate for the “microcontroller” part of the course material, the “C” part, not so much. While I certainly could use a refresher, my experience with… a number of more recent languages (C#, Java, JavaScript), which are descended from C/C++… and the fact I already know C and C++, kind of makes that part mostly just review material for me.

Although, I believe C with Microcontrollers, is not exactly like C as an application language… there might be some surprises there for me. At one point I tried using some “C” trickery on an Arduino and… well… it didn’t go so well… for some reason Arduino’s aren’t so good at handling dynamic array’s using “calloc” or the more C++ like “new” statement.

Anyhow, should be interesting if my application is accepted. Otherwise, back to the O’Reilly books for me.

Amazon Dash Button Hack

Well, I saw this some time ago and I just couldn’t resist it.

When I first saw the Amazon Dash buttons, I thought… wow… how useless… a single purpose WiFi enabled IoT device whose only reason for it existence is to help you spend money on Amazon. Even worse, the buttons are technically tied to certain product lines. (ie. The bounty button is for bounty only products… BTW, I am NOT pushing any particular product here). However, I’d prefer… myself, the buttons were more generic and you could set the button up to order anything from Amazon Fresh or Amazon Groceries… there loss in my opinion. For example, there is no button, currently, for anything I like to drink… although the Mac and Cheese button is sorely tempting me… had the buttons been more generic, I’d simply set one up to order a case of Lori’s Lemon iced Tea from Honest Tea and cheerfully chug it while programming. But … no…

Amazon Dash Button

Amazon Dash Button

Ok, after I got over the laughter it induced when first seeing the buttons, I realized… actually its a bit intriguing none the less… I was completely curious about how it worked, particularly for $5.00. Adafruit.com curated some tear downs of the button hardware and rehashed some already existing blog posts about repurposing the buttons.

Here is the teardown and the rehash of Ted Benson’s Dash Button Baby Monitor hack.
Anyhow, there are two ways to repurpose the $5.00 button.

  1. Reprogram the hardware (definitely not easy)
  2. Cheat, and do not complete the button’s initial setup and monitor your network for ARP broadcasts (the easier way).

As a security guy by trade, I *really* don’t like the second option. It is an example of why IoT is so dangerous. However, for yucks (and time constraints), I went for the second option. The funny part is, while Ted Benson is in the process of teaching you how to hack the button, he is also showing you how to hack… the hack… the observant techie will see this.

So first… the victim…

Amazon Dash Hack Victim

Amazon Dash Hack Victim

I would never be caught dead ordering a case of water from anyone personally unless it was for some kind of emergency, so I figured buying the SmartWater dash button would help me resist the urge of wanting to use the Dash button for Amazon’s intended purpose. (And yes, I have one for ordering pet food and have considered one or two others; ie. the Mac & Cheese one).

So, as per Ted Benson’s instructions, I proceeded to go to the Amazon Shopping App on my Android Tablet and configure the button for use on my WiFi network. The last step in the configuration is to select the item from the buttons “product” line you wish it to purchase when you press the button. At this point, I just closed the app.

Next, a little Python magic on a Raspberry Pi like computer (actually its called a Wandboard Quad, and I use it for development work) and using the Scapy library. All the code examples and details are in the Ted Benson blog post and I won’t rehash them here. However there are a few gotchas in the post…

  1. The demo python code is missing “#!/usr/local/bin/python” on both examples, so either you add it or execute the scripts like this, “python dash-listen.py”.
  2. You must install Scapy… and… everything it relies on. The simplest way to do this is, is on any Linux distro with a decent package manager (apt, yum, etc….) simply, for example on Debian derived Linux distros, “apt-get -y install scapy” will do the trick. This will bring down scapy and all its dependencies. If you install Scapy any other way… don’t ask me for help, your are on your own.

Anyhow, following Ted’s instructions, I obtained the button’s MAC address. Then I altered the python script to suck up the MAC address from a config file (which will be capable of holding an arbitrary number of such addresses for the future) so they can be recognized; ie the file contains the button type, MAC Address and script to be executed when pushed. As mentioned, I already have one button deployed Amazon’s way to keep my cats neck deep in tasty cat food (see picture below of the little beasties) and to keep my lazy lower posterior from having to leave the house to get it). However, it also stands to reason I can also see this ARP’ed MAC address for this button and launch a script if need be, like emailing both my wife and myself to be on the look out for the impending delivery and adding a calendar entry on Gmail for the probable delivery date.

Deez Cats

These little eating machines right here

Now, I have all the workings I need to get the button to do something… first lets demonstrate that it works…

As you can see from the video, once the button is pressed, its ARP broadcast can be detected with a great deal of ease. Interestingly enough, you may have noticed the video is much longer then it needs to be. In this particular test the button failed to do something. Usually, the button flashes the white LED, then flashes red (ostensibly to indicate it failed to order anything). For some reason this time it did not do that. Not sure why, I suppose if a case of SmartWater shows up, then I’ll know. 🙂 You may have also noticed that I did not display the complete MAC Address of the button… read on to discover why….

I have not yet figured out what I will use the button for, although I have some ideas, clearly though, I have to use it for something that is not critical or terribly bothersome should, uh, ahem… something goes wrong… read on for details. This was more of a “I wonder if I can do this” kind of thing. Actually, I think reprogramming the button would be better. Primarily because, technically, this button can still work as Amazon intends it too. I just have to select something for it to order. Also, I have not yet figured out how to reset the button to work in some other WiFi network. It seems once its configured, then its locked into your WiFi network. Bummer…

…And, for the security minded, you may have noticed… or thought… well… if you can use Scapy to see the ARP broadcast… then can’t you just make Scapy forge an ARP packet with the same MAC Address???? Why yes… you certainly can! This would essentially simulate a button pushing.

I can just picture a scene straight out of the Simpsons, with Nelson Muntz mercilessly running a Scapy script while shouting, “stop pushing yourself, stop pushing yourself”. (for the Simpsons deprived…).

So… for example, say I rigged this thing up through IFTTT (If This Then That, ifttt.com) to control my household Wemo switch which drives a living room lamp. Then some idiot can simply instruct the python code to turn the lamp on and off all day long just for giggles by repeatedly issuing forged ARP broadcasts. This is why I did not display the last 3 octets of the MAC address… I’d just be giving you the keys to the python script by showing you that.

Bonus points for anyone who can tell me why showing the 1st 3 octets wasn’t so smart either!!!

If you reprogram the button instead of using this ARP method, which it is a rather brain-dead hack, you can add some security to, perhaps, for example, actually have the Dash button reach out to IFTTT itself over HTTPS instead of using a go-between python script. But reprogramming the button requires much more sophistication in dealing with electronics and a boat load of TIME which I do not currently have.

Anyhow, something to consider.

Any suggestions for what to use the button for?

I suspect my next attempt at this, will literally be to build a similar device using an ESP8266 Wifi module ($2.50) running NodeMCU and an ATMEL AT-Tiny 85 microcontroller ($0.95) with a quartet of cheap push buttons and a 3.3v coin cell. Altogether, the cost should be on par with the Dash button, but the ESP8266 and AT-Tiny85 are *much* easier to program. Which opens the possibility of greater security features and significantly better configuration (ie. use in multiple WiFi networks) and possible greater non-security features too. It will just simply be, much more flexible.

CSI: Cyber

Matt reviewed CSI: Cyber some weeks ago… today I was channel surfing and came across this weeks episode…
I decided to watch it, just for kicks.

Hmmm… they found a suspect at the IP Address of “957.x.y.z”… in of all things from the header of a commercial email… which… no email these days includes the originating IP addresses anymore… nor is any digit of an IP address larger then 255….Um…

So, I won’t be watching this again.

But, I will say this… if non-IT security people watch it and start becoming more aware (or scared) of cyber-security issues… I don’t think I can complain about that…

U of Witwatersrand Strikes again…

Often I get an idea and it seems the fact that others get it too kind of confirms somewhat that it was a pretty good idea. Ever mindful of a Friedrich Nietzsche quote, however…

The surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently.

At least keeps me from thinking its a great idea. Great ideas would have to be unique, or even revolutionary. It also makes me mindful that, perhaps… just perhaps… maybe it wasn’t such a good idea after all. Anyhow, as always, history will be the judge.

To wit, a few blog posts ago (on another blog) I mentioned I bought a Wandboard for one of my projects. I have to say, the thing has grown on me; I love it. Its become my little workhorse.

While shopping around for it, I thought, given its specs, it might make for a good cluster node. Being a bit more powerful then the Udoo Quads I own, which would be another good choice for a low-rent cluster as well. Anyhow, I stumbled across the University of Witwatersrand‘s High Energy Physics Group’s Wandboard cluster and thought, “…well ok then… someone else thought so too”.

So, yay, my nVidia Jetson TK1 arrived today, woohoo… 192 CUDA cores, it has most of the same important specs of the Wandboard, plus… 192 CUDA GPU cores! Given the state of computational science these days and everyone running to GPU’s for math or computation heavy tasks, I thought… hmm… might make a nice cluster node.

nVidia's Jetson TK1 Board

nVidia’s Jetson TK1 Dev board

Turns out, darn it… U of Witwatersrand thought so too… they just installed an 11 node Jetson cluster and are currently running performance tests on it. They are speculating that they are going to get some 3850 GFLOPS out of the cluster.

Hummpff… go figure… wish I had 11 Jetsons. 🙂

Hmm… ok then…

If anyone is reading my blog and recalls, I once opined on the state of semi-conductor technology, most notably how physicists and engineers extended the life of silicon transistors instead of having to resort to much more expensive gallium arsenide. I also mentioned that its likely that the performance envelope of silicon has probably been reached unless someone comes up with a good idea like the last “doping” process.

Well, Stanford beat everyone to the punch with a way to make gallium arsenide cheaper.

According to Aneesh Nainani at Stanford, the average gallium arsenide 8in disc, cost about $5000 while the average silicon 8in disc costs about $5, you can see the problem reaching an on par economy of scale using gallium.

However, Stanford found a solution that will dramatically reduce the cost… see here… for details.