Showing posts with label security. Show all posts
Showing posts with label security. Show all posts
Reliving the Past - The Visitor Access Kiosk
Monday, May 11, 2015Before this sounds horribly boastful
This project was a defining moment for me as a developer. I had, up to this point, been mostly focused in Web/Database applications that were used internally. I had quite a few wins in this area, but nothing that ever extended beyond the walls of the company (beyond a project a few years ago that was sold to a vendor of ours whilst we were in the throws of Bankruptcy).Stupidly, I had never thought to just "google it". At the time, Global Crossing didn't put videos on YouTube, and I'm not entirely sure how it even got there. It was a *monumental* task and I was *not* the right developer to be doing it, but I love code and I love solving hard problems (from time to time). In this case, the VP of our department (an awesome guy who's name I'm omitting because I haven't asked for his permission), asked if I could create a kiosk that would allow a visitor to contact someone in the office from a secure visitor lobby, have a video/voice conversation with them (one way video, inbound to the employee only), would print a one-day-use badge with their picture, name and relevant information and give them a way to sign out when their visit was over. This was to replace the need for a dedicated receptionist, or a pen/paper log-book.
Some implementation details
Unfortunately, the only copy of the original whitepaper has been removed from Microsoft's site -- it was for Office Communicator 2007 R2 (technically we ran it on this version, but it was developed targeting the pre-release of R2), so I'll include that hereI implemented it as a WPF application, touch-only (at a time when a 1024x768 SAW touch screen was $1500). I used a barcode scanner, a simple label printer attached to a USB -> Ethernet device, a Logitech camera, and a ThinkCenter PC running Windows XP (stripped of everything unnecessary, including the Explorer shell. All of the code was my work (that's a statement of fact, not pride -- I would be embarrassed by that code today). My good friend and former coworker George Morell and I handled the operating system hardening -- when you have a guy at your disposal that can tell you the location of every obscure OS registry setting from Windows 2000 to Windows 8.1, you defer to that incredible expertise. And our security guys did some network hardening to ensure that if someone took a sledgehammer to the device and grabbed its ethernet port, it'd be worthless to them.
Most of the application was written in C# (.Net 3.5, I think, I remember thinking ... "generics?" ... like "templates in C++?"... no ... not exactly) with some bits in C and one really nasty bit in C++ (it was the camera interface). It was not a difficult thing to write, but at the time, it was a difficult thing fore me to write.
Without further ado, the Visitor Access Kiosk.
I had to laugh while watching it. The UI is comical today, but keep in mind that this was developed at a time before Windows 7 was released. Windows Vista and Windows XP's "chrome" were the inspiration behind the design. And I had some fun with XAML.
Fix: MS10-049 and SSL problems connecting to https:// sites or Google Talk
Friday, August 20, 2010Problem
When connecting to Google Talk, or to some other SSL based sites using Internet Explorer or any browser that uses the operating system's SChannel libraries, the connection to the site fails.
Other things you might see
TLS v1.0 is turned off.
Wireshark shows a reset happening very shortly after the Client Hello for SSL.
The Fix
Use SCVS for TLS:
For non Windows 7 hosts, apply this fix (Reference)
Fire up RegEdit, navigate to:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Create a new DWORD item called "UseScsvForTls" and set it equal to 1
I'm not sure if this was unique to our environment, but we discovered TLS 1.0 was disabled and the above fix didn't cover that. To enable TLS 1.0 in IE, select Tools|Internet Options|Advanced Tab. Scroll to the bottom and check the box that says TLS 1.0.
But why?
In at least some cases, a proxy server monitoring https traffic was interfering with the connection. If the proxy was bypassed, all was well with the world on Windows 7 and lower hosts. If the proxy was not bypassed, hosts failed without this registry key, and Windows 7 hosts failed at all times since the Windows 7 patch pays no attention to that registry key.
Obviously it's something related to the patch and the proxy server in my case, but I'm not sure what. I'll update this when I find out.
Other Posts on the Subject
Google Talk Support Forum Entry (No, I wasn't the original poster, but I replied)
Specific Incompatibility with Cisco VPN 3000 concentrators
10 Reasons to Abandon your ISP E-Mail Account
Thursday, June 7, 2007So lets start:
- Most ISPs don't provide "forwarding" service when you decide to leave them for the competition.
If you're not planning on switching ISPs right now, you can give your friends and family a heads up. Start by sending a message to everyone you know has your existing e-mail address. Then setup a mail client rule to forward all messages to your new account on GMail (my preference) or another service.
For added convenience, setup another rule to reply to those messages with a notice that your e-mail address has changed. You have a much longer buffer period for your friends to update their address (or ignore). You can even take it one step further and change the message to say "I no longer check this account, if you want me to receive this message, send it to "mynewaddress@gmail.com". - You're no longer tethered to your ISPs service.
ISPs know that the fact that you being hooked into their e-mail service is something that may prevent you from shopping around for a better deal. If you're not tethered to their exclusive services, you can leave for that better deal (assuming you live in an area that actually has broadband competition!). I have close friends that kept their AOL dial-up subscription for years because the pain of giving up their @aol address was too much (they've all moved on now, thankfully ... that, or I've just stopped having friends who would use AOL). - Your passwords aren't sent in plain text.
Your e-mail account is the window into your world. Most people use their "ISP" e-mail account like they use their home phone. They provide it to those with whom they engage in transactions with (such as the Credit Card Company or The Bank).
If you make a habit of using open access points, or public access points, that silly mail client of yours is probably sending your password plain-text every 5 minutes. If someone gets that password, they simply have to collect some e-mail from you to determine who you do business with, visit the site, and use the "Forgot my Password" link, where most services will conveniently send your new password via e-mail.
Make sure you pick a service that encrypts your ID and Password by default. GMail requires an encrypted connection on their web site, and if you use their free POP access, it'll be encrypted there too.
I'm dumbfounded by the fact that so many ISPs do not even allow encrypted authentication on their e-mail servers. - You can take your e-mail with you.
Yes, it's web mail, so if you want to check it from a location other than home, you probably can (assuming the internet connection your using isn't blocking web mail). In addition, with GMail you can access your e-mail in the same manner you're already likely used to ... via Thunderbird, Outlook, Outlook Express or your favorite mail client at no additional charge.
Yahoo! also offers POP3 mail, however, at the time of this writing, you'll have to subscribe to their premium service. - You can send e-mail when you're not on the same network.
This is similar in nature to the above, and may already apply to your ISP e-mail. Some ISPs only allow you to send mail if you're connected via a set of IP Addresses that they own. This means when you're using an open WiFi Network, you can receive mail just fine, but cannot send it.
Most ISPs have addressed this limitation, but if yours hasn't, you'll now have the ability to send and receive via either your web based client, or your own local client. - You may find the Web mail features to be better than your mail client.
I have both a GMail and Yahoo! mail account that I regularly monitor. As far as GMail is concerned, I'd rather use GMail than Thunderbird. It filters spam well, it integrates with their instant messenger client (as does Yahoo!), it allows for lightning fast searching of my old mail, and it redefines the way I work with e-mail by grouping messages in conversations and allowing me to apply labels.
Plus it's just dead simple to use. Not that I'm confounded by the "intricacies" of Thunderbird, but I find I'm more efficient using Web Mail. - You will probably get more space for your mountains of mail.
This was the initial reason many people switched to GMail. They offered you 2GB of server side storage for mail (Indeed, some people even use it as a backup service). - You now have that backup you keep meaning to do.
This comes with a caveat. If you aren't using both a local client and the web client, you're actually in worse shape than if you had only the local client and failed to backup. At least you'd still have the drive or computer that failed if you wanted to pay for costly recovery services. If Yahoo! or GMail loses your mail, you're stuck.
That said, if you use a local client regularly (and you're leaving your mail on the remote server), you now have redundancy. A lost drive does not mean that all of your e-mail is gone. - Mobile E-Mail Access may be easier and less costly.
Of course, this always depends on who you choose as your e-mail service provider. For me, accessing my GMail account on my lousy Motorola E815's sorry excuse for a Web Browser is actually quite painless. They did mobile e-mail right, and it shows. It's easier for me to get into their service, check my mail, and get out than it is to use the kludgey POP3 client. And since my cell phone provider requires that I purchase the software to even check e-mail via my mobile phone, it costs less. - SPAM and Malware are handled better.
Maybe you'll be a little more careful with this new account and not put it on your MySpace profile, or give it to every company that asks for it. You're starting fresh, give it only to trusted sources. Set up more than one account or use services like Mailinator for disposable e-mail addresses.
In addition, because Google or Yahoo! know about *all* of the spam their receiving, you may find (as I have) that their spam filtering far exceeds what even the most sophisticated of mail clients can pull off. Sure, your ISP may have server-side spam filtering also, but they probably don't have the user base that Google or Yahoo! Mail does.
In addition, most Web mail services scan all attachments for viruses (typically only when you use the Web interface). If you've been lax on your Anti-virus updating, this may save you.
GET vs. POST - Save your users!
Friday, May 18, 2007First, a little explanation. GET and POST are commands issued to a web server. Your browser uses the commands to request a web page, and provide information to a web application.
In the case of GET, this is often done via a specially formatted query string. The text and information of this query string is visible to the user assuming your application resides in a normal browser window and not one where the address has been hidden from view.
GET can be used as a method for sending form data, and it is used often in the case of Search Engines. Simply search for "dog" on Google and you'll find this URL:
http://www.google.com/search?source=ig&hl=en&q=dog&btnG=Google+Search
GET is convenient. As you can see from the above URL, I could just as easily encode a link like this and you'd be sent away from my blog to a search about a dog. In fact every link that goes to a web page is a GET operation, not just forms like Google's Search form that use the method GET.
POST is a method that is primarily designed for sending form data (it can be used in many other ways, but we'll skip those for now). POST data does not appear in the address bar like GET data. It also cannot easily be encoded into a link.
So which should I use and when?
The answer is simple, but the solution is sometimes painful. GET should be used only when the operation it is performing is considered safe. Safe means an operation that is looking up data. I've even heard it said an operation that "asks a question", or "navigates somewhere". In the case of a search engine, you're asking a question. In the case of a link, you're navigating somewhere.
What's more important is knowing when GET should not be used.
Rule #1: Never use GET in a login form or to send sensitive data
I know that this should be obvious, but I've seen it before. For those who are still scratching their heads. When you use GET in a login form, the user ID and password of the logged in user will appear in the address bar. This is called exposure. :-)
I've seen plenty of older e-commerce sites that send credit card data this way. This is "bad" on more levels than I can get into here. Just don't do it.
Rule #2: Don't use GET for any operation that modifies something.
This is where most people fail. I've logged into my banking site, and I'm looking at my account. Next to my account is a link that says "Delete". It links to the following URL:
https://www.mynicebank.com/accountOperations.aspx?Action=Delete
My, how convenient is that to code? No form necessary, no javascript, no buttons, no hidden values, just an anchor reference. That's also leaner HTML.
Technically it works. Since I'm logged in and have an authenticated, encrypted session, it's thought to be secure (assuming your account number isn't in that querystring, it might actually be secure).
Unfortunately, some browser extensions and some alternative browsers do something called "Look Ahead". And it does exactly what it sounds like. It looks at the page you're on, and pre-loads all of the links on the page, figuring that you're probably going to click on one of them. The idea is that if the browser pre-loads all of the links, and you click one, it'll already be in your cache and navigation will run lightning fast. Unfortunately, the Look Ahead doesn't know anything about what the link actually does.
If mynicebank.com encoded the delete link that way, and I was running FasterFox, my bank account might be gone lightning fast even though I never clicked the link.
Rule #3: Never use GET to send large amounts of data
This is less of a rule and more of a suggestion. Some older web servers and browsers limited the length of a GET request. Most, nowadays, don't. I've even seen some clever hacks that use TinyURL to store entire files.
While writing this, I discovered a great resource over at the w3c. If you're still curious, check it out. Those guys are a lot smarter than me and probably came up with something I missed.
Subscribe to:
Posts
(
Atom
)