Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Discussions

William Stacey staceyw Before C# there was darkness...
  • Secrets

    PerfectPhase said:
    staceyw said:
    *snip*

    I don't disagree with what your saying, and have said before in this thread that I don't like the idea.  But this is a internal request, and the thread started was started on the premise of 'If you had to....'

     

    @ScanIAm

    The Customer owns the hardware, OS and their people sys admin the box.

    We provide a software package that runs on this box.  This software has serveral wcf services that talk to each other.  They are secured with service accounts and X509 certs.

    The apps default trust boundary requires that the admin be deemed trustworthy and assumes we are protecting the system from people the customer does not want to access the system.

     

    The question was what if we want to protect the system from the customer themselves.  If we wanted to make some of the wcf service endpoints private.

     

    As has been pointed out in my original post and by AndyC and others this is actually impossible given where the current trust boundaries are; we do not trust the people who run the system under us, the OS. 

     

    So the question should have been, how would you slow someone down finding a secret from your code.

     

    Anyway thanks everyone for the discussion.

    Tossing some outside-the-box ideas on the wall:

    1) I guess you really had to, you could use something like Citrix and keep all the code on server.  Then nothing on client side to hack.  One of the selling points of this solution.

    2) I also wonder if you do something like a VM with your complete client environment running in a ~secure password protected and encrypted VM.   The VM would have only your admin rights and user accounts as needed.  Local admins would not have access. The clients could remote desktop into app and/or log into the VM as a normal user with no admin rights and use client locally and rely on NT security.  Could play with and tune rights (execute only, etc).  As a side effect, could also make versioning and change control on the client side a simple matter of shipping or reinstalling a new image file.  In effect, your placing a client environment inside a client site still controlled by you.  Allowing only remote desktop to your *app (not a console session) would seem to be about the tightest you could get.

  • Secrets

    As AndyC said "That still boils down to "How can I identify the calling program?" and the answer is still "You can't. Ever"
    http://blogs.msdn.com/b/oldnewthing/archive/2006/08/18/705957.aspx"

     

    1) Makes a good point that there is user security only, not application security.

    2) Assume your network api is a public interface, because it is.

    3) Assume other client software can and will call your api.  For that matter, in general you want other client sw and/or extentions to call your public api.  The server side is the barrier and should expect all calls are bad. 

    4) I don't need to decompile your client library or figure out your secret hiding places.  You have already published a beautiful api for me that I can reference and call with my own program.   Your code does all the work for me.   Interactive/prompted userid and passwords is only way.  I must know a proper id and password to gain entry on any call is the goal.  Once I prove that to you, then I should be able to do anything your public api allows without compromising anything on server side - now I am on the hook because you know it is me or I gave my password to someone or they guessed it (so then turn it off and investigate).  If I am allowed to do bad things with my id, then server security needs more attention.

  • Secrets

    PerfectPhase said:
    W3bbo said:
    *snip*

    We have a app, it's a shrink wrap system installed on the clients infrastructure.  When installed, all our services are protected with X509 certs and a few other things, so from the outside we're quite secure.   Are services are all WS-* type WCF services,
     
    I now have a new request from sales, we have to protect access to our services from third parties that are trying to integrate with our system, where the third party is on the same box and the system admin is deemed to be complicit.  Seems they want some sort of 'certified partner' program.
     
    So I'm faced with finding a way of identifying which inbound calls to our services are from our services and which are not, given the fact that they have access to our service accounts, binaries and X509 certs!  Kind of like protecting a DRM key in a media player binary.

     

    Oh yes, one last thing, no internet access either.

    "where the third party is on the same box and the system admin is deemed to be complicit.  Seems they want some sort of 'certified partner' program"

     

    huh?  Why they have to be on the same box?  If sales can't afford another box for 3rd parties in the DMZ, then they can not be serious about security.  When on the same box, you may as well do nothing.

  • Secrets

    For casual, I may do one of below:

    1) Use DPAPI and add secondary entropy from a string inside your app.  Decide if you can use User level DPAPI security or have to settle for Machine.  If using machine, it may be no better then hiding password in some hash. http://www.obviex.com/Samples/Dpapi.aspx

     

    2) Use some long random string in your app as the raw AES key.  Hash it (once or more times) and take the number of bytes you need for the AES key.  Encrypt and Decrypt your data using AES and your key.  This will stop most but people who can open your app in reflector and read your code to figure out how your hashing and making your password.  Could also use some Obfuscator on your app to raise the bar more. 

  • Google cries foul when they can't meet customer standard.

    Interesting.  Seems pretty clear cut to me.  They did not me 145 requirements - end of story.  I like when they say "people need to change the way they work to use our stuff" (or something like that).  Smart client sofware is smart for a reason.

  • Monadic ​Network-​Infrastruct​ure

    Charles said:
    exoteric said:
    *snip*

    Not joking at all. Just set up the first lecture filming, actually.

    C

    Wondering if Greg Meredith and Jonathan Edwards may be on to the same thing with trees and distributed trees from different directions?.

    http://channel9.msdn.com/shows/Going+Deep/E2E-Whiteboard-Jam-Session-with-Brian-Beckman-Greg-Meredith-Monads-and-Coordinate-Systems/
    http://channel9.msdn.com/posts/Charles/Jonathan-Edwards-Programming-Futures-and-Declarative-Objects/

    Greg has mentioned something for a second that his lamda calculus could address any node in a tree even if all nodes was not local.  That would seem to hint at a solution to distributed data trees across the web. And if it works remote, it works local, so would seem to be a unification model.   Curious to see the many problem spaces that could help with (i.e. distributed cache, transactions, minimal data copy, etc).  Seems as if monads and functional have really started to crack some big problems for the industry and have some synergistic effects.

  • [Linux] Kernel 2.6.35 released

    cool.  What is linux?  Wink

  • An idea for a tablet UI

    BitFlipper said:
    staceyw said:
    *snip*

    Yes of course you can use the emulator (although it doesn't really emulate the hardware well in many cases I am finding). But this is not something you can tell consumers to do. The point is not to emulate the WP7 eUI, the point is to run WP7-like apps on a tablet (or any other PC that has a touch screen) in full-screen mode. Plus you don't want to sell a tablet and tell people that the WP7 emulator is going to be your primary UI. In addition, it could take advantage of the bigger screen, just like iPhone apps that were adapted to iPad can.

     

    @staceyw

    Not sure about ipad, but AFAICT MS Ink already has those issues worked out for the most part.  It is largely application specific on what events you want to listen to and/or disable at proper points in your application and your UI design.

     

    I think this is already handled at the harware/driver layer. If you bring the stylus close to the screen, the hardware/driver simply stops forwarding touch events, so software never need to worry about this. At least this is how I believe it works.

    "Yes of course you can use the emulator (although it doesn't really emulate the hardware well in many cases I am finding). But this is not something you can tell consumers to do. The point is not to emulate the WP7 eUI, the point is to run WP7-like apps on a tablet (or any other PC that has a touch screen) in full-screen mode. Plus you don't want to sell a tablet and tell people that the WP7 emulator is going to be your primary UI. In addition, it could take advantage of the bigger screen, just like iPhone apps that were adapted to iPad can."

     

    @BitFlipper.  I was not suggesting the UI be Wp7 based.  The UI (i.e. your Shell) app would be WPF and/or SL out of browser.  But to run native WP7 apps on desktop, wouldn't you still need an emulator control to emulate at least the screen sizes and hw (i.e. buttons, usb, phone, etc).  Or are you saying any WP7 app should be able to run up-level on WPF?

     

    "I think this is already handled at the harware/driver layer. If you bring the stylus close to the screen, the hardware/driver simply stops forwarding touch events, so software never need to worry about this. At least this is how I believe it works."

     

    Last I looked at Ink apis, you could control these behaviors and handle various different events.  Depending on the app, you may want different behaviors in different contexts.  I could be wrong as it has been a while.

  • An idea for a tablet UI

    BitFlipper said:
    wkempf said:
    *snip*

    Although I can't imagine that that will be a good stylus experience on the iPad. The touch-screen is primarily designed for touching with the hand, and I am sure if you rest your hand on the screen while using that stylus (like you do when writing on a paper pad) that it would pick that up. The newer tablet touch screens can do both touch and stylus, and when it detects the stylus, it turns off the touch, meaning your hand resting on the screen won't interfere. And as you say it has no built-in handwriting recognition.

     

    Those are the kinds of things I'd like to keep doing on a tablet. I use OneNote a lot, and I have an endless number of sketches. From designing various things I build at home, to drawing out the frameworks for new software projects. I have drawings helping me to visualize complex software problems, to handwritten notes etc. UI designs.  I also use mind-mapping software, which work really well on a tablet. None of those will work well on an iPad type device.

     

    So my idea is basically, let's take Herlequin's Win 7 tablet (see above) and add a front-end that essentially can run the type of apps that WP7 will run, with all the advantages that it brings. I would love to have something like that on my Windows 7 tablet, and I think it would be great to develop apps for something like that (in addition to the WP7 version).

    "Although I can't imagine that that will be a good stylus experience on the iPad. The touch-screen is primarily designed for touching with the hand, and I am sure if you rest your hand on the screen while using that stylus (like you do when writing on a paper pad) that it would pick that up. The newer tablet touch screens can do both touch and stylus, and when it detects the stylus, it turns off the touch, meaning your hand resting on the screen won't interfere. And as you say it has no built-in handwriting recognition."

     

    Not sure about ipad, but AFAICT MS Ink already has those issues worked out for the most part.  It is largely application specific on what events you want to listen to and/or disable at proper points in your application and your UI design.

  • An idea for a tablet UI

    BitFlipper said:
    staceyw said:
    *snip*

    Yea, that is what I was thinking. Something like this does not require any commitment from OEMs because as far as they are concerned, it is just another software component that ships with the default Windows 7 installation. Maybe the only thing they need to do is decide whether it will run as the default "UI" when the user powers it up the first time. And since it isn't an integral part of Windows 7, as you say it doesn't require any changes to Windows 7 either. It's just another "application".

     

    But to re-iterate my point again, I think what could make this work is if it is tightly coupled with the SL+XNA framework that ships with WP7, because then it can tie into the same app store and developers can, with only a small amount of effort, make their apps work on both WP7 and this framework. Basing it on WPF or anything else would take that advantage away.

     

    Are people really not seeing how well this works with iPhone/iPad? There is a very close relationship between iPhone and iPad. Anything less and we are back to square one. It is sad to say, but I believe MS needs to take (another) page out of Apple's playbook here. They have already copied Apple almost 100% with WP7, so why not go all the way?

     

    EDIT: As you mentioned, I was also thinking about how this could even work on the desktop where MS is pushing touch as well. You run this framework, and now you have access to the WP7 (+WT7) app store where you can download these apps. There aren't a lot of advantages that MS has over Apple in this regard, but this could be another (other advantages I see; better dev tools, more developers familiar with the platform, multiple hardware choices, multiple carriers, a better business case, ability to learn from Apple's mistakes (although they choose to make a few of the same - no initial C&P or multitasking), having a proper API out of the gate (where Apple had none initially, unless you count web-apps), etc.  

    "But to re-iterate my point again, I think what could make this work is if it is tightly coupled with the SL+XNA framework that ships with WP7, because then it can tie into the same app store and developers can, with only a small amount of effort, make their apps work on both WP7 and this framework. Basing it on WPF or anything else would take that advantage away."

     

    @bitflipper.  Guess I am confused.  You have the sl+xna framework avail for W7 and VSExpress to develop W7 apps and the phone emulator.  So this all would work today AFAICT.  Not sure if phone emultor works outside of VS or not.  But that would be the only missing piece - a Wp7 emulator control for SL and wpf.  You could then do all that stuff inside your new application.  They don't need new OS skus and hope they reduce skus and not add more.