Archive: January 23, 2016

<<< January 22, 2016

Home

January 24, 2016 >>>


Saturday morning post

Saturday,  01/23/16  09:57 AM

A nice quiet Saturday morning, no football (for the first Saturday in a looong time), and lots of interesting code to write... what could be better?

One of those weird first-world problems: this morning one of my Slingboxes stopped sending audio.  (I have two of course, one for each Tivo.)  I swapped and suddenly they both worked.  So that was nice, but me being me, I had to spend two hours figuring out why.  At the end of which, I never did figure it out, left them swapped and ... blogged :) 

Behind Facebook's $2B acquisition of Oculus.  When this was first announced, I couldn't figure it out; it felt like one of those "well, the market will like it so our stock will go up" kind of acquisitions (like Google buying YouTube).  But I'm warming to the idea.  VR is going to be huuuge, and Facebook were probably smart to get out in front of it. 

Of course part of my interest is that VR is going to be a big driver of Visual Search adoption :)

Related: for VR to be truly immersive, it needs convincing sound to match

What I think is more important: Leap Motion is perfecting natural hand gestures for VR.  When we can interact with VR in addition to perceiving it, then it will become real. 

And check this out! - the high performance icosahedron.  That would make anything seem real. 

Excellent!  Blue Origin sends its rocket to space ... again.  We have to point out that "space" here means 100km, not at all the same as reaching Earth Orbit, but this is still impressive.  Love it! 

SpaceX Dragon hoversAnd SpaceX's crew capsule is one step closer to flight.  In the race between SpaceX and NASA, who will win?  (We will all!) 

This looks interesting: Kim Stanley Robinson's Aurora: space is bigger than you think.  "Like some of the best Golden Age science fiction, Aurora is a story about engineers troubleshooting hard technical problems. But Robinson's generation ship is plagued by biological problems that are much trickier than the mere physics of propulsion."  On the list! 

Philip Greenspun makes a great point: Why doesn't Windows 10 retry the password as if CAPS LOCK were off?  It already reminds you that CAPS LOCK is on... in case that would help.  This is a classic case of engineers implementing the solution without thinking about the problem. 

Are global warmists simply juicing the latest years' temperatures?  Yes.  Sadly, every year is now reported as being "the hottest year on record", because of these "adjustments".  Meanwhile a snowstorm on the East Coast has come in, right on schedule.  I'm not a global warming denier, just a skeptic, but the behavior of the "scientists" studying climate change is highly suspect.  Especially since their grants come from those with a stake in the "crisis". 

Excellent news: first new US nuclear power plant in 20 years scheduled to open in Tennessee.  As we switch from carbon to electric cars, we'll need many more of these. 

What do you think, is Tesla the car that killed glamour?  I disagree, because glamour will catch up with reality.  Someday soon carbon cars will seem like horse-drawn carriages do today.  They might seem glamorous, but only in a nostalgic kind of way. 

Speaking of nostalgia, here we have the Harmony Cartridge, every Atari 2600 game ever made all on a single SD card.  Imagine the entertainment locked into that one little device.  Amazing. 

You knew this already: The US Postal Service has not earned a profit since 2006.  Sigh.  If this were a business it would be out of business - or would have transformed itself by now. 


Here's a cool visualization of wavelengths of different colors.  They look so happy :) 

for extra credit, can you image adding X-rays?  (they are super-short)  What about radio?  (they are super long...)

 

 

Kara (Star Wars episode VIIa)

Saturday,  01/23/16  01:21 PM

Tired of rewatching Star Wars VII?  Check out Kara:

I think Star Wars is by far the most fan-augmented film series ever

 

 

a better way to handle passwords

Saturday,  01/23/16  03:44 PM

<rant type="Saturday afternoon">

A key challenge in client/server systems which exchange information over a public network is authenticating users.  Typically users are identified by a userid, and authenticate with a password.

For security purposes passwords should never be stored, and so generally the server stores a hash of the password.  This enables validation but not recovery; if a user forgets their password it must be reset.

Because public networks are insecure, passwords should never be transmitted over the network, instead, they should be hashed on the client.  In addition to eliminating any possibility that passwords could be captured in flight, this also means that any kind of server error would never reveal a password, since the server never even sees them.

Note: the popular oauth2 authentication mechanism does send passwords over the network.  So it's a standard, but it is not that secure.

Hashing passwords on the client is good, but it leaves the possibility that a hashed password could be intercepted and replayed.  To solve this, maybe the current time could be combined with the password before hashing it?  Call this H(T+P).  But can the server validate this?  It knows H(P), and it might be able to guess T (although synchronizing time is never easy), but H(P) and T don't yield H(T+P).

Okay, maybe the current time could be combined with the hash of the password?  Call this T+H(P).  Now the server can validate this pretty easily - still the time sync problem - but it is insecure; if T+H(P) is intercepted then T could be guessed, allowing H(P) to be isolated.  A new T could be combined with H(P) to enable a replay.

Maybe the current time could be combined with the hash of the password, and that could be hashed again?  Call this H(T+H(P)).  The server can validate this if it can guess T, because it knows H(P) already.  This is secure and makes replays impossible.

That leaves the problem of time synchronization.  This can be solved with a little extra complexity by having the client request the time from the server.  The server responds with an encrypted time value V which is opaque to the client.  The client combines V with H(P), and then computes H(V+H(P)) and sends that to the server.  The server can validate this easily, because it knows V and H(P).

So here's the better way to handle passwords:

  • Client prompts for userid and password
  • Client computes hash of password H(P)
  • Client requests time token from server
    • Server responds with time token V (encrypted and opaque to client)
  • Client combines token with hash of password, and hashes the result, H(V+H(P))
  • Client sends userid and hashed hash H(V+H(P)) to server for authentication
    • Server validates H(V+H(P))

It's actually not that hard, and nicely secure.  You're welcome!

Oh yeah, this is how eyesFinder's authentication works...

</rant>

 
 

Return to the archive.