In an effort to provide our customers with the most secure and efficient product possible, the team behind PortalGuard is proud to announce the release of version 5.6.4! This latest version of PortalGuard follows a recent round of penetration testing by Veracode – a third party solution brought in to ensure that PortalGuard is as secure as possible. As a result of that test, PortalGuard version 5.6.4 comes equipped with some new bells and whistles to enable our customers to maintain security without sacrificing usability.
Primary Updates – Server Hardening and 2017 Penetration Testing
As a result of the latest round of Veracode testing, PortalGuard 5.6.4 now ships with various configurations options that will ensure that your instance of PortalGuard is as secure as possible.
Standard Server Hardening
Enable HTTP Strict Transport Security (HSTS) Protection
HTTPS is all the rage these days – just look at the recent warnings from the fan favorite tech giant, Google. Cyber security is an important commodity in the digital world. It is therefore understandable that administrators and end-users alike expect a certain level of security when information is shared in any way. That’s where PortalGuard server hardening can improve your already secure communications by taking a lot of the guesswork out of the equation.
HSTS protection involves enabling your webserver to send out a “Strict-Transport-Security” header within its typical responses. By doing so, the web server forces access to occur over HTTPS, even if the initial access was attempted over an unsecured HTTP connection. The benefits of this feature are voluminous, but chief among these is the ability of HSTS Protection to prevent SSL Stripping attacks.
Do you want to ensure that your passwords are protected beyond the shadow of a doubt? PortalGuard has you covered.
Require SSL on PortalGuard Session Cookie
An important aspect of Single Sign-On (SSO) is the usage of Session Cookies to establish a trust within the confines of the browser. With unsecured session cookies, attackers can potentially obtain the information and use it to impersonate legitimate users. By configuring PortalGuard to require SSL on the session cookie that it utilizes for SSO, you ensure that your environment is much less vulnerable to the dreck of internet, with no impact to your standard usage scenarios.
Displaying information in plaintext sounds cool and all, but security is the name of the game. PortalGuard is not going to be outdone by a Guy Fawkes mask.
Reduce Session Timeout
Session Timeout is a standard feature in web server access and usage. So much so that Microsoft has a neat little document on its usage in Internet Information Services v6.0. The long and short of it is this: Session Timeout determines the length of time a session can be idle before the server forcible ends the session.
Session timeout is a standard security feature that has a slew of best practices associated with it. The most notable best practice is to shorten the length of time that a session is considered ‘active’. With PortalGuard, updating this session timeout is as simple as making a change to a single line of text.
Per Veracode’s recommendation, PortalGuard not installs with a shortened session timeout, so we’ve done most of the work for you. It’s our pleasure.
Generic Error Messages
“Generic error messages” sounds like part of the first answer to the Jeopardy question: ‘What would annoy your end-users the most’. While that may be true, utilizing generic error messages serves a much grander purpose in the war against the less than desirable portion of the internet – the folks in the black hats.
Attackers generally hope for – and too often get lucky because of – overly specific error messages during activities that rely on increased security. A prime example is when an attacker attempts to break into a login without knowing a username OR password. Oftentimes, error messages help attackers confirm that at least part of their guess is correct (in this case, the username).
Of course, implementing generic error messages will not only frustrate potential attackers, but could rub your end users the wrong way as well. This security feature is a prime example of what it means to make the tough call between security and usability. Thankfully, PortalGuard has a full set of features to keep you on the fine line between the two.
Our development team has also added new features for administrators to configure that will impact end-users more directly.
Password Prompting for Account Management Changes
Enabling password prompting for account management changes in PortalGuard is an important addition from both a usability and security standpoint. This feature treats important account management changes the same way your Operating System treats administrator level installations/configurations – by requiring a verification of identity.
Imagine that you have just logged in to your PortalGuard SSO Portal from the Public Library and you’ve only now realized that you need to go ask the librarian for the proper source before you finish your paper and email it to your professor. At this point, you have already logged in and your account becomes vulnerable as soon as you stand up. Oftentimes, this may be harmless. However, as PortalGuard also manages your recovery options, it is important that those do NOT change without your knowledge.
Even momentary lapses in judgement are protected by the new password prompting feature for account management changes.
Detect Terminated Sessions
Aside from driving certain puppets crazy, cookies are extremely useful for the average end-user. Cookies are a major force behind a successful and simple SSO implementation. Cookies even serve to assist in streamlining the user experience. However, as with many usability features, cookies are prime targets for hackers and other ne’er-do-wells. Attackers love the session cookie because it is used for impersonation.
Standard implementation allows session cookies to be shared throughout an IIS farm. Sharing these cookies enables a login session to be active regardless of which server is being hit. When the end-user completes a logout action, the cookie is then deleted. However, this implementation is vulnerable to session replay attacks if attackers grab the session cookie before it gets deleted. This allows the attacker to impersonate the end-user for the duration of the session cookie. Nobody wants that. Well, nobody helpful, anyway.
As an added security bonus to our customers, PortalGuard now has the ability to write session cookies that have been manually logged out to a separate SQL table. From there, PortalGuard monitors for and prevents re-use of said cookies. This has no impact on standard usage. End-users will be none-the-wiser to the update, but attackers will find themselves at a loss for unfriendly impersonation.
Today, We Eat the Bear
Security does not need to be a nightmare. With PortalGuard, our policy is to continue providing customers with a product that acclimates to an ever-changing cyber-world. We do this all without detracting from a positive user experience. In version 5.6.4, the PortalGuard product is stronger and more usable than ever – letting you focus on what matters.
Previous Blog Product Updates: