Disparate identities? No thanks.

We all are used (or at least adapted) to keep and reenter a multitude of passwords.

They follow us everywhere - at work, when home, even when we're calling the bank on the go.

Security is a complex concept. Sometimes things that feel "intuitively right" are not in the best interest of securing your access.
Quite often, we are secured FROM accessing the services we so desire...then we resort to the oldest and least secure SMTP protocol that is long overdue for Rev.3 or Rev.4.

Many have adapted the use of "password manager" tools / addons.

Let's consider if there is a better alternative to existing solutions.

In few example cases, I will show how "feel-good" solutions, that are often "specifically designed" to improve your security, will actually decrease security of your access or even open ill-considered backdoors into your systems.

Case 1. ID Federation vs Multiple ID

Imagine controlling several separate security domains.
This happens most often at work, where you use one ID to logon to your PC, then another one to connect to your (Development Environemt/Model Environment/External VPN/Internal Applications etc).

You may have another username (a).
You may have to use slightly different usernames (b).
Sometimes you use exactly same username (c).

What IS important is you do not care to use different passwords in each domain. You would go crazy if you did, especially in case (c).
"Domain Name" is often not considered by the Application developers, and users are not always aware to which domain they are logging into.
Sometimes domain name is not even shown, especially in cases where applications are not designed for, and hence would not allow cross-domain logins.
What IS ALSO important is that there is no easy way to make sure users use different passwords in every domain.
Your SAP solution would not check Active Directory and make sure you use a different password.
Where are we ending with this non-SSO enviroment?

Users like to use same passwords everywhere.
It is enough to hack one enviroment and then reuse same password in other environments.
The thinking that non-SSO environment would "protect" against a password compromise is not often substantiated in practice; it is "false intiution".

How easy it is to protect against potential compromise?
We'd have to make users change passwords in every domain.
They may not even remember all passwords, when some were left behind and unused!
When disaster strikes, many doors will be open even though the storm is already gone.
When people leave the company, several non-integrated systems may still contain active credentials.
This is especially bad for VPN or other internet-exposed systems that are not AD-integrated.

What's the best architecture for multiple domains controlled by same people?
Use full SSO, one login connects users to all services at work.
Through IT Policies, make sure that every app deployed supports a form of integration with your most important credential data, Active Directory.
Prefer Kerberos integration over LDAP. LDAP would not support multi-domain environment easily.
Let application developers, modelling and vendors build a one-way external trusts towards your single forest root domain.
This is often safer, and is always cheaper that external "integrations".

Additional advice - use AD as your master DB. If you use external ID providers (Oracle, IBM) then those must have admin service accounts into your Production AD. This is bad...
External vendors (or their subbies) may be able to reset passwords of your CxO and read their email / access documents. Again, those service passwords most likely will be moved around the world over unsecured SMTP emails, often on "Cloud" providers and multiple governments looking over the shoulder.
Instead: Let your forest root domain controllers keep all IDs safe and ready to be reused in your forest child domains. Let DC talk to DC to automatically reset computer account passwords at predetermined intervals. No humans mucking around.

Case 2. Policing the passwords.
In password credential management, there's a number of parameters that often make even "experienced" people make stupid mistakes.
Every time, the whole password lifecycle process must be considered in an end-to-end manner.

The basic password policy parameters include:
- minimum password length
- maximum password age
- minimum password age
- password history
- password complexity checks
- password change warning period

Many of those parameters require consideration of how your passwords are: set initially; distributed to users; reset by users; reset by service personnel; aged and requested change; accounts disabled etc.
Let's take a quick example of CONTOSO company.
They have set password history to 24, and password minimum age to 1 day.
When passwords are reset by the helpdesk personnel, they are dictated over the phone to users calling in for a password reset.

Issues? Oh yes!
Firstly, when dictated over the phone, several users in the call centres (sometimes abroad) get to hear them out, spelled clearly and nicely.
Secondly, the two parameters they set, were designed to prevent the same specific unsecure situation - users recycling same passwords indefinitely.
But because these parameters designed to reach the goal via different means, only one or the other of them should have been used.
Using both, while seeming to "improve security", simply by tweaking all the knobs we see there, in fact cause a very insecure situation.
Password History is a barrier for users to always select a new password when changing it. The depth of password history log defines how many passwords user have to invent, before reusing the old and loved one.
Set it to 1 and users only have to change it twice - first time to invent a new password (the current one goes into the history log) and then back to the second password. Two passwords can be recycled indefinitely.
Set it to 12 however, and I doubt the users will go through the pain of changing passwords 13 times (inventing new ones) in order to reuse their favourite mot-de-passe.

In case of CONTOSO, however, the minimum password age was set to 1. This parameter was designed for cases with no password history.
Users would have to WAIT AND USE the new password they just set or got assigned BEFORE they could ever change it again.
This means that all newly assigned passwords, that were probably overheard on both sides of the phone calls, cannot be changed immediately by the user.
It also means that if someone overlooked your password as you were changing it, you'd not be able to change it once more when that person leaves the room.
They would have to use the passwords as assigned at least for one day. Compromised new passwords stay compromised for at least 24h. Not good...

What this means in practice is that passwords reset by the service desk are never changed by the users. Not on the next day.
Never - until the next expiration cycle.
There is no way to force users doing that.
The only way out is to change the policy and set minimum age to 0 and check "Must change password at next logon".
The password history will take care of "inventive" users trying to revert back to old and loved passwords.
As of now, users tend to stick with very simple and possibly compromised passwords well beyond the first day.

As for the password expiration period, it should not be left at default 14 days. In 14 days, many users are reluctant to change passwords so far ahead of time.
At the same time, 3 days is a bit too short - users may be compelled to change it on Friday and they won't remember the password Monday.
Five days seems the best choice. Users who receive the warning on Monday will have full week to think about doing it. They'd know they need to do it "this week".
It the pesky dialog pops up Friday for the first time, 5 days is good time to postpone it "till next week".

Password complexity? Of course.
If you serious about complexity, you should write your own PASSFILT.DLL.
Include dictionary lookups, as well as proper non-generic error messages towards users, so they know why the new password they tried to choose was a poor choice.


Case 3. External domains
Consider your "work" environment is fine-tuned and well-considered, time-tested and pen-analyzed.
How can you be sure your users are not using same password on their Facebook?

Well, this is where our discussion will lead us to the next gen of ID management, the frontiers of developments ongoing in various bodies and corporations.

Remember Microsoft CardSpace?
This was Microsoft's first attempt at "embracing and extending" credential management on the websites, "out there".
By design, web developers would have to include CardSpace support in their websites.
Then, once users connected to the website, it would send a signal to Internet Explorer to indicated that it accepts CardSpace.
Come on, fire up your XP machine and check in Control Panel.
It was basically same as Windows Credentials Manager (still present in Windows 7 and 8) - only for websites.
You could fill up, save and one-click-reuse so called "cards", one per site. Each card could contain your names, email, as well as "salted association ID" that would be used in place of password on the particular site that generated and saved the card.

Now consider the SmartCard standards.
Many computers still have the readers. But it has been a long time since I saw someone use a smartcard. OK CBA folks I know you do :)

The real reason why smartcards aren't popular is because the current standard sucks.
It does - because it hosts only one certificate. It seems designed only for "work use".
One certificate, same thumbprint - very easy to track the user.
This is definitely not a good architecture - for privacy reasons.
There's also no controls designed around what sites can access which certificates.

A better architecture would see the SmartCard standard extended and merged with some concepts of the Microsoft CardSpace component.

1. From a hardware perspective, each SmartCard would need to be able to keep up to 1024 user certificates (or other credentials), one in each separate isolated cell.
2. Each cell would be signed by a special website certificate, and verified via full DNS name. Other sites would not be able to send requests for that particular card.
3. One per-card PIN would unlock all cells, but each individual user card request would be screened by OS UI and approved/denied by the user.
4. OS would support new card creation by suggesting values from the user profile (name, nickname, email etc) but the user would have the right to override all values to establish a new account with a new service.
5. Some government sites would only accept "verified" cards that were issued by specific government sites/bodies.
6. Cards would not be "locked" to specific countries, they would be open for any new web services globally.
7. It would be possible to combine multiple "government verified IDs" on one card.
8. During new account creation, a uniquely-generated credentials would be stored on the card, only accessible by the site that generated it.
9. Some websites would offer to reuse government IDs, while allowing to create a new "local" account to anyone.
10. Optionally, a plain-text password can be displayed on the screen, to be taken by the user and used on computers without the new smart card readers.

With inception of such universal standard, all woes about passwords would be solved and the internet would become a more secure space.

It is time to move away from insecurities of keyboard keystrokes into the area of specialized chips and certificates controlled by the openly reviewed and secured hardware/OS standard.

Instead of building ID around Facebook, it's time to ask for universal standards for the new generation.

Ask your local Member of Parliament to support this.

Share and repost in social media!

Help to propel the cause to get rid of password headache and insecurities.

Chime in the comments as well - do you develop something like this?
Can you help developing this?

Built-in tracking protection in IE10+

A simple trick to help you thwart attempts to track you on the web.

It's a little-known built-in feature that applies to Internet Explorer 10 and later users; yes, you should update any prior versions you may still have, even if you do not use IE - many system components are using its frames.

While in Internet Explorer, press Alt-X or click the Tools button on the toolbar (most right), select "Manage Add-Ons".

Click "Tracking Protection" on the left - you will see a pre-defined "Your Personalized List" on the right.

Click the list and then click "Enable" button below.

Click "Settings" button below and select "Automatically Block" on the dialog that opens.

"OK", "Close"

Now what happens is IE will detect tracking frames on all websites that you visit.
If there are more than 10 occurences (different sites) having embedded the same tracking scripts, it will be considered a tracking network and will be blocked from placing an identifying cookies on you.

Hopefully this helps stopping the trackers "profiling" you, i.e. gathering info on types of sites you visit, and placing you into certain categories.

Possible uses of tracking involve targeted advertisement, market research for correlated traffic, audience statistics etc.

Not bad for an un-advertised feature that is given for free to all.

SHAZAM 6

Shazam will now listen to your music in background. How convenient.

"Windows" 8? Wait a minute

Microsoft Windows 8 is a very brave endeavor on Microsoft's part.
It essentially aims to replace, revolutionize the user interface that people use to "compute".

Wait a minute... "Compute"? Well, it seems that this term is obsolete, too.

Most of the times people don't crunch numbers, they are mostly after consuming numbers.
Modern PCs performance depends heavily not only on the pure computational power, but on storage transfer speed, network speed and memory size (even if that's video memory).

Did you notice Microsoft's stubbornness applying the "Windows" moniker to all their Operating Systems?
Is not it time for a product name change, as opposed to just the number?

Effectively, on a mobile device, we would not have the Desktop metaphor as invented by bright minds of Xerox PARC, and later implemeted by Apple Computer Inc.
Hence, we won't have overlapping "windows" (think "paper sheets"), representing different applications.
The "fourth screen" is too small, to have many different windows. We would have one window (possibly with many panes, as in highly acclaimed alas mismanaged webOS). Or multiple "tiles", replacing iOS's boredom of icon grids.

So they are not windows anymore, but "tiles". So why not "Tiles 1.0"?
Certainly, Microsoft thinks about itself in a very serious tone. They know they have to be brave, but consistent naming gives users false impressions, that the next OS is the same old, but better.

Ask many, and they will opinion - it's the new world, but not necessarily "better" in all senses. It's "different", and time will tell how quickly it will improve and be accepted.

Microsoft has learned to "think different" after all. Kudos.

Now, to the essense of what's going on.

Intrinsically, laziness wins, even when there are other grave considerations against it.
Did you notice, there's no ideology anymore, that would foster utmost strive for self-improvement and creativity in masses? The world is driven around money, not high ideals to achieve. Money is a carrot, it is also a stick.
With Information Superhighway (Bill Gates, 1995) being built on scale, and penetrating every house, one important thing has happened.

Digital Communism.
It has arrived. There is a mechanism, a technology invented and machinery built that makes [some parts] of former social regime obsolete. DMCA, ACTA, PIPA, SOPA, ring a bell? They are trying to reing it in, still wrap it under Capitalism, but "times they are a'changing".

When a major technological breakthrough happens, the social regime has to change.
Remember feudalism? Once a certaing advances have been made in producing mechanical machinery and steam engines, electricity were invented, these allowed material goods to be produced in quantities (sic!) that led to major changes in quality of life. This became Capitalism in most parts of the world, some have tried to build Communism, and very few have built a Socialistic-like societies (thank you, Sweden). There's no more feudalism - at least globally.

With Internet giving people "near-free" access to information, another social change is happening.
We have recently seen a wave of resistance from "undemocratically chosen" lobbyists pushing laws while the general public was asleep.
One big thing not solved yet - how to make new things "near-free" for everybody, in a decentralized manner.
But hold on, nanotech is coming.
Once the fundamental problem of easily "copying" material things verbatim is solved, "goodbye, Capitalism".

When it comes to gadgets and widgets we use, I observe a worrying trend.
A Personal Computer used to be thought of as a "bicycle for a mind", an open-ended thing that you would have full liberty to program, assign to any task you'd wish.

Nowadays, PCs are being replaced by a "shopping cart for a mind", a TV with many channels.

Most people who use computers now (as opposed to 70s and 80s) have no capacity to program them, they are formed by the Capitalistic regime to absorb what's being fed via "channels". Those who are not lazy, are building their own "channels", and take part in existing social mode, but on a different side.
Ironically, it's a bicycle which is preset to so many roads; you could always buy more "routes" for it, but all routes have to be approved, no riding around Whtie House anymore.

The conceptual idea of SmallTalk OOP language - to make PC programming so easy as to let anyone build programs for it - has been betrayed, privatized and forgotten.

The big mainstream capitalistic companies will have very strong control over all developers, very soon.
They will enforce digital signatures, Trusted Computing, and will revoke access of developers, following only their own internal company policies, not the government laws that cannot interfere with go-to-market strategies of private companies.

When Microsoft's transition to Tiles complete, we will only install what Microsoft likes, or allows us to install. Everybody in Metro development will have to be on good terms with Microsoft.
Microsoft may take a policy of accepting only "prudent" developers.
Doesn't it remind of something?

Customization options will be limited.
Did you notice it's not possible to use own color schemes in UI of major OSes?
Back in XP/2000/98/95 era you could paint windows your own colors.
Soon, even Wallpaper will go way of Dodo. Your only consolation would be to go buy more new tiles.
Reminiscent of Zamyatin's "We".

But most importantly, TV is back with vengeance. Just pick your channel.
Oh and what a TV is it.
It's a TV that watches you, knows your moves, your Contacts and Calendar.
The vendors only have to offer free "convenience" of backup for all of these.
Maybe it won't be offered, but built-in, mandated.

A lifetime account, anyone? The government would create it for you as you're born.
When you grow up to buy your device, just apply your RFID tag in your forehead and logon. A new ritual.
You will be able to apply to transfer it from MS to Apple or Google, but this will only increase number of parties who know a lot about you.
The irony is that Macintosh was started with the ad denouncing exactly the system they have been so instrumental in building.

I know you must be thinking I'm over-dramatizing it now.
Yes, I am. Some of it may not happen. Only good things will happen if every user's aware and informed, and uses own judgement.

Just remember, Gods live in the Clouds :)

RSA compromised. How to protect?

In a disappointing bit of news last Friday, RSA is compromised by "an extremely sophisticated cyber attack".

This time, for real.

While RSA does not disclose exactly what was stolen, knowing the technology, one can still design a mitigation strategy.

I will recount options for those who's eager to do something to protect themselves.

1. Switch to a different token vendor. This is the most disruptive and costly measure, but if your trust is lost, and you have the budget, this may be your strategic option. It will require to replace your authentication server, and may introduce other problems as well as disrupt business. While RSA took the lion's share of the market, there are still other companies who make tokens and develop two-factor authentication technology, you just have to look out. Besides, "security by obscurity" principle, while often being laughed upon by experts, seems to work for many customers.

If you prepared to wait and see, I would advise the following mitigation strategies to reduce the risk of being exploited by someone logging in on behalf of your user:

2. Replace all SecurID tokens. Call RSA and request all of your tokens to be replaced by new, UNCOMPROMISED tokens. This last one is important thing. Unfortunately, you won't be able to verify if your new tokens were compromised, unless RSA publishes full list of compromised token's serial numbers.

Depending on exact fields of data stolen by hackers, and the way RSA kept their token records, you may have the following options:

3. If the data stolen includes token serial numbers and private seed keys used to initialize tokens, but does not contain token-to-client mappings (every token in the list is "anonymous") then attacker may not know which token they should recreate for attacking your company. Your protection measure may be to remove serial number white labels from the tokens, and file off (yes, I mean mechanically) the embossed serial numbers on the back of your tokens. This would probably require a temporary recall of tokens from your users, unless you can delegate the task to your end users. Also ask you users to never give tokens to anyone, even "just to see", and never leave them unattended or exposing the back side (upside up on the table). Also be sure your internal records, containing [previously public] serial token numbers, are secured and were never compromized. If this cannot be done, seek another option.

4. If stolen data records contain seed keys, serial numbers, and client names linked together, the worst has happened. Someone can recreate your token, and the attacked will know which company the token's for. This effectively removes one layer of protection (something you have). Remember, though, that still have other layers. One option would be to require all users to change PINs. You can increase complexity requirements for PINs, for ex, require 6-digit PINs where previously they were 4-digit only. Since only one part of your security mechanism was compromised, you still may rely on user PINs and obscurity (unknown VPN address, unknown VPN group password, unknown user name, unknown PIN), depending on your business requirement. Also remember, that, as tokens expire, the exposed data becomes more and more obsolete with time. In the interim solution, you may want to consider options.

Keep safe.

NB. This article does not constitute a formal advice, nor will I accept responsibility for you taking my advice, as well as neglecting it.
Every business should carefully revise their security mechanisms, based on new input, including this article.

Patriot Act for all

There's no Outlook Express in Windows 7 anymore.
Say goodbye to your encrypted emails to Assange, people.

Terrified by VISA

On many occasions already, I have been "burnt" by one new feature that VISA system is rolling out now: 3DS (3D-Secure). It is also known by name "Verified by VISA".
This feature involves a third-factor authentication - an additional password one should know in order to perform online transactions - but ONLY AT 3DS-ENABLED sites.
Sounds funny, isn't it? Does VISA think that I would 'prefer' to shop at the very sites that give me this nuissance? Here's my recap.
Of the three different sites that had this feature enabled, none of them really worked for me. I opened trouble tickets in all of respective companies' systems.

It took me few rounds to make sure the issue is not pushed into my issuer bank. Obviously, it's easier for a merchant to ask you try contacting your bank - then they don't have to debug the process and interact with different parties themselves.
OK I took that advice - not happy with results though.

The first thing that strikes you as a consumer, that once you enter you card details in a secured merchant's site, once the 3DS-enabled site determines that your card is a subject to that weird security experiment, they redirect you to a third-party site!
Without letting you know what's gonna happen. So, in my case, when I filled the card details and clicked "submit" i was struck by a pop-up window at obscure address (www5.arcot.com) which required me to re-enter my card details PLUS the 3DS password (which I did not have then).

Now, didn't this look exactly like phishing, to my unsuspecting eye?

OK I did some research and found out what that was about. Now, I needed the 3DS password. I called up my bank, and they were able to supply me one.
But still, the system just did not work!

Secondly, why would I need a separate password, when I have my PIN already?!?
Why not use that? Or my online banking password, which would be checked by sending request to my bank, not to a third-party, cloud-based, untrusted-by-me, server.

After some rounds of talking to the parties involved, I decided to
"opt-out" of this 3DS joke and called up my bank to do that.
They were unable to do that, quoting VISA as my contact point.
VISA did not do that favour to me either!

All I could do is switch to my other card. My credit MasterCard.

I am not getting a VISA for me next time.

Cracking RSA SecurID

Yes, I cracked it! Read on for details.

There are surprisingly few hits on Google, if you search the topic.

So I, having the token, decided to take the matter into my own hands.

First of all, you'll need clean well-lit place and a strong knife.
Click over to Picasa and see the slideshow:

Crack RSA with only hands and a knife

For those who are lazy to go there, the most intriguing part is how easily can some circuitry contacts be exposed, and that means one can temporarily gain possession of your token, run some attacks on it, replace the glued-on stub and you will not notice a shit!

Could this be the reason they've obsoleted those?

E-mail encryption with FREE certificate

Hi, I've just discovered this interesting offering from DOCOMO:

The only caveat, compared to Thawte's WoT which came way of Dodo:

It does not verify persona.

So, what it's good for, and what - not?
It's still attractive for those who want to play without pay. I believe this case covers 90% or more, however sad that may sound.
It's also good for personal authentication as long as you know that:
(1) e-mail address belongs to an identified person (say, your friend whose e-mail you can positively identify from your previous transactions)
AND
(2) that it's really your friend who's gotten that free DOCOMO offer first.

Because even though your friend still may have access to his e-mail box, so may the bad guy have. And it's not hard for that bad guy to jump first and get that certificate, and peruse it for his deceptive purposes.
There is no persona verification, nobody goes to WoT notary with his passport and another photo Id, so whoever gets that certificate, and has access to the e-mail box (with no SSL used and abundance of free open WiFi it's not hard to do) - can positively forge his identity and make you believe that you are communicating over encrypted channel to your trusted partner.

In other words, "better than nothing", but "nothing for some".
Try it, use it, message me...

Note: did not work in Opera 10.10 (PC), had to use IE

Kaspersky vs proxies

Trying to find best antivirus, I have tried Kaspersky and here's what I have to say.

While it may be OK for home usage, it's a no-go for many corporate environments (like mine) which use script-driven proxy setup.




It just does not support .PAC script-based proxy setup, and so did not work for me.
And by the way, my previous companies also used such proxy setup.






Too bad for Kaspersky.
Not to speak of the higher pressure it puts onto system...
I tend to incline more and more along the way of thinking that it's software popularity is based more on marketing gimmicks like "personal touch" a-la Peter Norton, that quality merits.

And by the way, have you tried the free Microsoft Security Essentials?

It's got great usability! I can't speak of it's protective abilities (I'm sure Kaspersky will) but it's so easy to use and puts very light load on system, and nothing beats free. Recommended!

Thawte Web of Trust to kiss goodbye soon

In my email today was a sad announcement - Thawte, a well-renowned company providing security solutions to the Internet (mostly SSL certificates for web sites) is canning the free "Web of Trust" service on Nov 16th.

Web of Trust was a way to give people some electronic privacy in form of e-mail cryptography via freely-issued certificate.
That's the kind of stuff you'd configure in Tools-Options-Security menu (Outlook Express or Outlook).
I say "some" because the company might still keep your private key in some storage, and whoever has proper laws on their side, may get to that part of your e-privacy.
Any way, it's better to trust ONE government that trust EVERY intermediary provider, hacker, sniffer, rogue admin or the like.
That's called "reduction of attack surface".

"Why would we need Thawte, there are free tools for generating certificates" you'd ask.
Because a certificate has to be trusted, by default, each OS comes with an ample set of "root" certificates, those to whom every computer on the net has absolute (but not everlasting) trust.
Personal WoT certificates are signed by Thawte's CA (which are trusted via pre-installed root certs coming with most OSes) so your wot-secured e-mail would not cause a verification problem.

Anything singed by an untrusted root CA (certificate authority) is NOT trusted by most computers out there and will cause a problem that I briefly explained here.

What is Web-Of-Trust and how it helped keep constitutional right for personal privacy?

WoT is based on Notaries. A WoT Notary is a voluntary (unpaid) person with certain level of trust (not less than 100 points) who can certify that he has seen enrolling persons and verified their national ID (passport, driver license etc) and have recognized that they provided enough proof as of their name. The only piece of info that goes into WoT certificate is person's name and e-mail address, so that addressees (and e-mail client software) could positively identify the authenticity of e-mail correspondence.
"WoT Trust spreads thru the grapevine" one could say.

Basically speaking, you can get free "noname" certificate right now, but you can have your name on it only when you get some points from WoT notaries (by visiting them in person and showing your IDs).
As soon as you get your cert, you could SIGN your e-mail. Any change of your e-mail in transit (except for headers) would be detected by the addressee. In fact, that is like having your written signature on it.

As soon as your addressee has own digital ID, and because he has your public key from your signature on first e-mail, she could ENCRYPT their replies back to you, so that the content of e-mail could not be seen.
That's how privacy works. Both parties must have IDs and there must be a transfer of public key (for ex. via first signed e-mail or offline).

There are alternatives, of course, and I welcome you to discuss them in comments.

I am Sergey Zak and I'm a Thawte Web of Trust notary.

CheckPoint SecureClient

I have spotted one pleasant peculiarity (feature) of CheckPoint VPN SecureClient on Mac OS X - it warns user of imminent session expiration.

In my 4 years of usage, the PC version warns you only when you have lost connectivity, and annoys user with "Reconnect" requests for new RSA code.
But that, magically, never happens on a Mac. In fact, Mac users are politely warned BEFORE issues occur.

How gentle and nice of you, CheckPoint!

BTW if I was to compare CheckPoint VPN to Cisco VPN, I must say that Cisco has one annoying feature turned on by default, and it takes a lot extra effort to fix that - all traffic goes to VPN tunnel.
This means that if remote secure network does not support a service you want to have (SMTP, POP, Skype, whatever), you're toast until you disconnect.

Quite important for telecommuters.

All in all (taken into consideration the admin tools) CheckPoint software is much more usable and has better GUI.
I only wished their installers properly removed (upgraded) their previous versions...

Insecure certification? Say no.

If you, like me, have worked for some corporation, or even smaller company with an Intranet, then you'd recognize this kind of screenshots:

It's a long standing security issue and the one I just read an article about here

For people without due understanding of certificates and why they are used, this is a non-issue - they just click "Continue" or something to that effect - and go on.
But the devil is in the details, as we know.

I think it's about time we stopped allowing that.

Besides presenting a usability issue, namely a "nag" dialog, it also de-voids one of two purposes of certificates - it does not verify the server's authenticity, allowing for so called "man-in-the-middle" attack.

The second, remaining, purpose is encryption against eavesdropping, but this one will also be crippled if you're talking to "the wrong" server after clicking "Continue" on invalid certificate.
Simply because the eavesdropper will be the non-authenticated (fake, malicious) server with similarly incorrect certificate, to which you'd blindly accept connection.

Such practice had been "convenient to user", who needed a way to access things, and "merciful to developer" who did not want to spend money on SSL certificates from established Certificate Authorities.
Well, there's been epoch with no condoms, and people suffered greatly while not realizing there's an exit.
As more and more electronic fraud and hacking dilutes quality of online life, there's more and more need to establish better standard practices.
Now web looks like only richer folks can buy needed protection. The rest of us have to "blindly click extra".

Time to revisit what stops us from helping every website?

I would suggest to "close the cap" by disabling access from all browsers to invalid certificates.

The only exception left would be VALID self-signed certificates, but they should be separately indicated in browsers by a special icon (not the padlock as with CA-signed certificates). Such exception leaves out one vector of attack - DNS.

And for future development, there is a need to secure DNS, too.
I think there can be one solution to both problems.

An option to get certificate when registering your domain name!
(Directly from the registrar.)

Think of this - we trust DNS, should not this trust be augmented by certification?

Unfortunately, this would mean serious increase in business for registrars and decrease for CAs.
Well, good does not come without changing.
Besides, I think they are in the right position to lobby this as a new web standard.

For registrars, that would be an additional competition vector.