Idea Exchange Priorities

[JackDunaway]

Just a little teaser on the interface for voting for your "Top 10 Most Respected" users. The list is populated with all users from the database who have a non-zero Reputation (your reputation is equal to the number of people who have you in their Top 10 - if you are on 8 people's Top 10, you have a Reputation of 8), in addition to the top 20 or so Kudoe'd authors on the LabVIEW board.

Is there someone not on the list you would like to add? No worries, just type in their UserID (mine is 88938, you can see it in the hyperlink of my profile page). For instance, you can see below that I added 117075, the highest-Kudoed non-ASCII user on the forums. Who is in your Top 10 is viewable only by you, but your cumulative Reputation is public.

And of course, to do CCFrog.gif and friends proper justice, the Avatars are properly animated.

    

There are a few hurdles still holding me back from releasing this Top 10 interface and IdeaVIEW (the interface for sorting, grouping, and investing in your favorite Ideas from the Idea Exchange, I'll give screenshot teasers at a later date).

First, user authentication. I want a 1-to-1 relationship between who-you-say-you-are to the IdeaVIEW server and your ni.forums.com username. The problem here is I am certainly not going to do a IdeaVIEW-server-side authentication with your password - your credentials stay between you (the client) and ni.forums.com. I have attached (as a zip, cannot figure how to save a library for previous version?) a client-side authentication mechanism that piggybacks on to your secure ni.forums.com login (look at the code, let me know if there are any security issues) that also scrapes your accurate post count since the service provider for these forums is, shall we say, arithmetically challenged. That accurate count is used to determine your initial "bank" for investments. I plan on using this client-side authentication just one time for an IdeaVIEW registration process (not a "process" per se, just a username verification and a new password creation for logging on to the IdeaVIEW server).

Secondly, hardware restrictions. Currently, I would be able to use my own piece of hardware at home as a server running LabVIEW homebrew server code, but uptime is an issue here. I have attempted to fast-track some PHP and MySQL skills so I can host the database and API on my website, but learning this stuff as I go has been throttled by my cranial horsepower limitations.

Finally, this project has become heavily tilted toward my own benefit of learning rather than any potential benefit the community would gain from having a decent way to view and vote for Ideas. It's been a fun sandbox of new toolkits and connectivity that I just can't spend time on at work, and I constantly get distracted learning how to do things better and more professionally.

So, check out my attached authentication code, give feedback, and stay tuned for the next few weeks... IdeaVIEW screenshots to come... 

[JackDunaway]

Another option for voting:

I hate registration. I honestly think that needing to register for this program in order to vote is lame. On the other hand, how can you keep "confidential" information confidential without some sort of logon authentication?

There's one more alternative: distribute the source code for the entire project that can be run by the client, but the small part for authentication and talking to the IdeaVIEW server would be an executable. This would allow me to hard-code a secret key into the executable, making messages back and forth from the IdeaVIEW server encrypted (obfuscated, at least). Is it possible to hack? Yes, but this method would completely solve the temptation of spoofing for all but the most diligent and nefarious of hackers. So 95% of IdeaVIEW could be run in development mode, with only 5% of the code "black-boxed" for security and identity integrity.

The one downside here: you would be passing your password into an exe black box, and that black box would send encrypted data to a foreign server that you "don't trust" (the IdeaVIEW server). Who's to say that black box is not also packaging your password and sending it to me? There's no way to verify that it's not without cracking the encryption - you would just have to take my word for it when I say "it's not". In my book, that doesn't cut it, so I'm torn with the practical/ethical implications of this method. Would a valid solution be to share this secret key with a couple of the most trusted community members, and that way you could take a few independent people's word that what's going on in the black box is legit?

Currently, I prefer this method better than an IdeaVIEW registration. Identity validation is totally client-side, and if it authentication to forums.ni.com succeeds inside that black box, the same black box sends your votes and identity (but not password!) to the IdeaVIEW server.

Thoughts? 

[JackDunaway]

It hit me this morning a few more ways of making this "black box" less "iffy".

First, rather than black boxing the entire messaging protocol to the IdeaVIEW server along with the forum authentication, only black box the forum authentication. That black box would return an 8-byte Unique IDentifier - an encoded version of your forum User ID. Again, mine is 88938, and it would be transformed into an arbitrary 8-byte number, for instance 0x3FC9F9B5B870BFB8. This encryption could be done with secret salt hard coded into the login exe - again, not totally fool-proof, but good enough. Currently, there are around 150k registered users here, which can be represented by 18 bits (2^18=262144) If I used a 64-bit UID, that's 46 bits of encrypted fluff - virtually impossible to randomly guess another UID unless you know the secret salt.

Still, I would want to share this algorithm with a few trusted community members who can all vouch that it's legit.

So, the GetLoginCredentials that I attached would become the "black box" executable and it's output would be a 64-bit UID, which would go in the header of any message back and forth between you (the client) and the IdeaVIEW server as your identification. You could feel free to try and guess another UID to spoof someone else's identity, but the probably of getting one right that the server would accept as valid is 1 in 70368744177664 (2^46).

Also, as proof that this "black box" is not sending your password to my server is simply the size of the UID - I can't fit a typical username and password into only 8 bytes, and if I can, you need to change your password anyway!!!

With this method, virtually 100% of the source code could be run from the project in development mode, so it will even be clear how communication back and forth with the server works. And even the black box source code can be released - just not the secret salt.

---

On another topic...

I realized a good server-side verification that client-side authentication is legit: just look at the Recent Logons to forums.ni.com. If the IdeaVIEW server receives a message from a client, it can verify that the requesting client is actually logged on and active. Cool!

With that being said... what the hell is the Grand Wizard doing logged on at over a dozen different computers???! Is he outsourcing his expertise to lowly-payed lackeys in all timezones of the world? Is this the secret to his success?! (altenbach, just giving you a hard time... but seriously? What's up?) 

 

[tst]

The black box could probably also be password protected, thus simplifying the architecture. However, I don't think you can verify the user is who they say they are without contacting the site yourself (at least once) to get some of their private info, since anything else could probably be faked relatively easily (the forum ID, for instance, is public).

Another alternative would be to have them perform some operation themselves for the login to work, such as posting to a common thread (ugh) or temporarily adding the hash you generated to their info (e.g. homepage), which you can then read using public access and use to provide them with a permanant hash. You could probably also offer the service as a locked automated service for those who can't be bothered and care less about their security.

So the process would be:

1. Input user ID.
2. Generate first hash.
3. Log in and paste the hash into the homepage field.
4. Tell the program to go read the homepage field and generate a second hash (this part will be password protected).
5. The program can now save the hash and the user can reset the homepage field.

As for the multiple logins issue, it's been around for years. If memory serves, the system logs every time you try to log in, even if you're already logged in.

[JackDunaway]

With regards to putting a hash as part of the public profile: this would be challenging. First, most information is by default not shared publicly (Location, Homepage, Personal Title, Personal Biography, etc...), and for the few people who have that information shared, it would be difficult to hijack a field and reset it to it's original value. At all costs, I want the procedure to be as easy as possible, with virtually no client actions except for typing in username/password.  Right now, I'm questioning the need for a server-side identity validation.

Password protecting the black box rather than distributing it as an exe is a good idea - the only VI I would need to black box is IdeaVIEW_ResolveUserInformation.vi (a subVI of my upload). I have already added the salted and secretly keyed hash as part of it's output cluster.

I still havn't gotten any feedback on GetLoginCredentials... has anyone used the VI successfully/unsuccessfully? Any suggestions on how to make the VI better? 

Message Edited by JackDunaway on 05-02-2010 02:51 PM

[TCPlomp]

well there are some fields, which you can make public in your profile, and you could just pick on of them.

For instance, how many of you still have an ICQ number?

The easy thing is that I don't see a valid reason of storing any data in there (your personal profile) and have no-one seeing it.

For me it would be very little work to get a valid hash and store this in my ICQ field and open up that page.

Ton

[JackDunaway]

Ton, thanks for the feedback!

The problem I see here is that if I were to put a hash in the ICQ field, I would have to modify your profile privacy settings from private to public. Whereas nobody has an ICQ handle anymore, some people may have a Yahoo, MSN, or AOL handle, which would undesirably be shown publicly. I want all actions to be transparent to the user since I don't want to require any client actions for registration, so anything that happens, I want it to be behind the scenes (e.g., calling methods on the .NET WebBrowser object, as shown in GetLoginCredentials). With that being said, I need to keep automated behind-the-scenes action very, very simple... it's fragile already... if the forums.ni.com designers change their variable names in their HTML or scripts, this code is toast and needs to be updated. The less I do, the better.

If you examine the code for ResolveUserInformation, you'll realize that it only works if the user is currently logged on to forums.ni.com in the scope of that application instance. As long as this VI is black boxed, I can reliably trust a client-side authentication, so I'm not as concerned anymore about a server-side identity validation. 

Still, looking for some feedback on that Authentication code... 

[Ben]

---

JackDunaway wrote:

...

I still havn't gotten any feedback on GetLoginCredentials... has anyone used the VI successfully/unsuccessfully? Any suggestions on how to make the VI better? 

Message Edited by JackDunaway on 05-02-2010 02:51 PM

---

I downloaded it looked at it learned some stuff then tried running it on my Winodws 7 machine hoping to learn more while wtching in execution high-lighting mode. It got locked-up, used Windows taks manger to close it then went outside to cut-down an apple tree.

Sorry but that is all I can report.

It did make me question how we can enusre our passwords are secure.

Ben

[JackDunaway]

Ben, when the program runs, enlarge the window so you can see all the elements of the front panel, including the WebBrowser object. As for your password security, it's as secure as the .NET layer SSL transactions provides. You have W7 - this is a dumb question, but do you have .NET 3.5SP1? I'm not sure what .NET version is required for the program, but that's the version I am running on both computers I have tested the software on.

As a side note, it appears that if you are logged on forums.ni.com from within Internet Explorer, the GetLoginCredentials automatically detects your being logged in without needing to log in again to a Microsoft browser (It performs a "silent" identity validation, which if it succeeds, in a later version I will not even show the login window).

Because of this "silent login", in order to Log Out, go to the "Nav to Login Page" state and wire in the other constant on the block diagram (it's currently wired to "https://sine.ni.com/niforum/niforum?forumDU=http%3A%2F%2Fforums.ni.com", wire it to http://forums.ni.com). This will allow you "Log Out" of the forums and click "This is not me" on the top of the page. Now, you can wire back the original constant and repeat the login process.

Anyone else had good or bad results?

[MikeS81]

Message Edited by MikeS81 on 05-03-2010 07:08 PM