All Things Being Equifax: A Cybersecurity Awareness PSA

October 4, 2017 at 10:29 am | Posted in cybersecurity | 2 Comments
Tags: , , , , , ,

Over 9 billion data records have been lost or stolen since 2013. In fact, experts believe nearly 5.5 million records are exposed every day. It’s no longer a question of whether a company has been compromised, but when it will happen, and how consumers can take steps to protect their data.

Not every data breach is the same. Sometimes the stolen data is already public, like your name and street address, or is encrypted to prevent its use by thieves. The most dangerous breaches expose plaintext data (data that is not encrypted or otherwise obscured) and PII (personally identifiable information), such as a government ID with an associated date of birth and legal name.

The recent Equifax breach is a serious security concern because of its breathtaking scope and sensitivity. The stolen data included social security numbers, driver’s license numbers, and other PII as well as credit card numbers. Unlike a username and password, PII is meant to uniquely identify you for your entire life and (usually) can’t be changed. If it’s exposed, you face an ongoing threat of identity fraud.

So what can you do in the wake of such a massive breach? What follows are the best security practices we can recommend, including advice from an actual (anonymous) employee of a big-three credit bureau.

(ETA: as sharp-eyed reader Carol points out, there are actually four credit agencies, though Innovis is typically omitted from these types of list. We have updated the post to add Innovis’ contact information as well.)

Continue Reading All Things Being Equifax: A Cybersecurity Awareness PSA…

The Great Password Debate – Where we disagree about password resets and failures (Part 3)

September 20, 2017 at 3:30 pm | Posted in cybersecurity, Knowledge, Technical Tips | Leave a comment
Tags: ,

This post is part three of our reaction to new recommendations in the National Institute of Standards’ Digital Identity Guidelines (NIST Special Publication 800-63), Appendix A – Strength of Memorized Secrets. You can check out Part 2 here.

In the Great Password debate that has been generated by the latest NIST guidelines, we (the trainers and experts on the Transcender team) find we agree with some recommendations and disagree with others. In our previous post, Josh discussed the way password complexity has been found less secure than longer passwords made up of simple words. In this post, we (Robin Abernathy, Ann Lang, and Troy McMillan) want to discuss NIST’s new guidelines for password resets (password age) and responding to password failure/account lockout (failed authentication).

Among the otherwise sound advice in the Digital Identity Guidelines (NIST SP 800-63B), we did pick out three points that cause us some consternation:

  • Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator. (Section 5.1.1.2)
  • Unless otherwise specified in the description of a given authenticator, the verifier SHALL limit consecutive failed authentication attempts on a single account to no more than 100. (Section 5.2.2)
  • When the subscriber successfully authenticates, the verifier SHOULD disregard any previous failed attempts for that user from the same IP address. (Section 5.2.2)
Love it a long time, or leave it every 30-60 days?

How many of you out there work for a company that requires you to change your password at a regular interval, usually every 60 or 90 days? Bullet point 1 states that this is no longer necessary.

Troy says: I disagree with this recommendation. I contend that changing the password at regular intervals DOES increase security because it shortens the amount of time it is available for disclosure. The logic behind this new NIST rule is based a failure of how people implement it, not a failure of the concept of password age. In other words, the concept fails because the users do not use unique or secure passwords. They usually choose a new password that’s similar to the previous passwords with a few character changes. This issue would be resolved with proper security awareness training and policy enforcement. Also, there are solutions out there that can prevent users from creating a password that is too close to a previous password. So while we understand what NIST is trying to do with this change, I personally don’t agree with it.

Ann says: I disagree somewhat. The theory is that if you’re ALSO making people choose much longer, easier-to-remember character strings for passwords, like IlikebigpasswordsandIcannotlie! Twoyears beforeI changeit lala hooray!, then you still have the advantage of the password being much, much harder to crack or guess from a mathematical standpoint. After reading through their breakdown of Authenticator Assurance Levels (AAL), I’d be okay following their password age recommendations for any site that’s operating at AAL2 or above.

(For what it’s worth, Microsoft’s 2016 Password Guidance for IT Administrators both counsels you to lose the mandatory periodic password reset, AND to educate users on choosing appropriate passwords and banning commonly used passwords.) Continue Reading The Great Password Debate – Where we disagree about password resets and failures (Part 3)…

The Great Password Debate (Part 2): Longer, Simpler Passwords Are the New Black

September 8, 2017 at 4:03 pm | Posted in cybersecurity, Knowledge, Technical Tips | 4 Comments
Tags: , , , , ,

This post is part two of our reaction to new recommendations in the National Institute of Standards’ Digital Identity Guidelines (NIST Special Publication 800-63), Appendix A – Strength of Memorized Secrets. You can check out Part 1 here.

Which of the following two passwords is more secure?

p@$w0RdCh34Tr#
ILikeSimplePasswordsICanRememberAndUseNotComplex

The first password is 14 characters long, well over the recommended minimum of 8 characters. It also meets many, if not all, of common password complexity requirements: it contains multiple special characters like @ and $, numbers like 3 and 4, and mixes uppercase and lowercase letters in for good measure. It does not contain a username or any repeated characters. At the Password Meter, I get the following rating:

password1_strength

The second password is a lot longer (over 3x), clocking in at 48 characters. If you think that is crazy long, section 5.1.1.2 of the new NIST  800-63B Special Publication suggests passwords of least 64 characters! But this password is pretty awful when it comes to complexity: it has no special characters or numbers, and it contains easy-to-read dictionary words. So you’d expect a really low score from the Password Meter.

But you’d be wrong:

password2_strength

What is going on? In a nutshell, according to the latest research, password size matters more than character complexity, even if the password strings together easy-to-read words. This is a harsh truth, to be sure, and the reason why requires a quick trip back to mathematical set theory and the world of bike lock combinations.

Continue Reading The Great Password Debate (Part 2): Longer, Simpler Passwords Are the New Black…

The Great Password Debate (Part 1)

August 22, 2017 at 4:49 pm | Posted in cybersecurity, Knowledge | 1 Comment
Tags: , ,

Are you overwhelmed by having to remember too many passwords? Why do some experts recommend using special characters like %, $, or @? Do you really have to change your password every 90 days? Which password method will keep your accounts and data safe from hackers?

Do you ever just feel like you’ve fallen into the password abyss?

Welcome to our new blog series, “The Great Password Debate!”

If you’re sick and tired of being sick and tired of keeping up with password complexity advice — which says to maintain dozens of unique special-character passwords that change every 90 days — you’re not alone. Bill Burr, who helped first come up with these password standards for National Institute of Standards and Technology (NIST), is right there in the password abyss with you:

I have maybe 200 passwords. I can’t remember all those obviously […] It’s probably better to do fairly long passwords that are phrases or something like that that you can remember than to try to get people to do lots of funny characters.

Currently, most authenticators make users create a combination of numbers, letters and symbols for a “safe” password. However, Mr. Burr has stated recently that he believes making passwords more complicated is NOT the best way to protect your information. He now recommends longer, simpler, and more unique phrases—and, apparently, so do the recently updated NIST standards.

So, what are you to do? Go with the tried and true methods of the past ten years, or step out with the new password approach? In our upcoming blog posts, we’ll delve into this issue, presenting various password rules and seeing how they compare with the latest suggestions from security experts. It promises to be a very L1v3LY D38473.

Stay tuned…

Shahara Ruth

Oracle Security Features – A Primer

August 5, 2011 at 3:52 pm | Posted in Oracle, Technical Tips | Leave a comment
Tags: , , , , , ,

As I sit here next to my distinguished colleagues who are working on Microsoft and Cisco practice exams for Transcender, I feel a little bit like an outsider, since I’m the only Oracle expert on the team. Many of their blogs lately have concerned security in the Microsoft and Cisco environments, so not wanting to feel left out, I thought it was appropriate to let you know that Oracle is no slouch when it comes to security.

A small but important subset of the security features that Oracle provides is the security surrounding user access to the database and subsequent access to different objects within the database. Since space and time are limited, I’ve chosen to discuss the top five security features as decided by yours truly. Ladies and Gentlemen (drum roll please), here are:

My 5 favorite security features in Oracle 11g

Number 5: DBA superpowers. In the past few years Oracle has given the DBA a number of additional capabilities for securing database accounts. Accounts can now be locked, passwords can be set to expire (password aging), minimum password length and password complexity can be established, and passwords containing mixed case characters can be enforced. A maximum number of failed login attempts can also be established, and if a user is unable to login after that number of successive attempts, the account will be locked. Password history and the reuse of the same password can also be controlled. You can choose whether passwords should be case sensitive.

You can even query a view called DBA_USERS_WITH_DEFPWD to find if you have any of those default accounts in your database still set with the default password. Do you really want a hacker breaking into your database because she knows that the password for scott is tiger (doesn’t everybody know that?). And, although not a security topic per se, the DBA can insure that users don’t consume an inappropriate amount of CPU resources, both at the individual command level and the session level.

Number 4: The Oracle password file. When properly protected, the password file is a much better way to authenticate remote DBAs than setting the old REMOTE_OS_AUTHENT init.ora parameter equal to TRUE. Relying on a remote client to be responsible for authenticating DBAs, in my mind, is like giving away the keys to the kingdom. The password file is a far superior method because it provides a single repository for authenticating DBAs. This file exists where it should be located, on the database server, and thus prohibits a hacker from impersonating a legitimate DBA and establishing a DBA connection from a client machine.

Side note: There is some confusion regarding the concept of the password file. It exists solely to store the credentials of a person with “super” DBA privileges (called SYSDBA or SYSOPER) who may need to access the database for the purpose of starting it up if it’s down, or shutting it down if it’s up. This is an alternative method for DBAs who may not have been given the traditional O/S authentication privilege to authenticate themselves. It has nothing to do with authenticating ordinary users. Users have only one way to authenticate themselves: by providing a username and password that matches those stored in the data dictionary of the database. And if the database is down – well, they are just out of luck until the DBA brings the database back up.

Number 3: Auditing improvements. Auditing is a feature of Oracle than has been around for quite a while. However, you may be unaware of some upgrades since the days when AUDIT_TRAIL was set to either TRUE or FALSE. Many shops these days, in addition to the traditional use of auditing to check for suspicious activity, are using Oracle’s auditing feature to insure that privacy requirements are being met (HIPAA, for example), that compliance requirements are being met (Sarbanes-Oxley, for example), as well as to gather statistics which are used as the basis for a proposal on a new business opportunity. New options for the initialization parameter AUDIT_TRAIL allow you to do a variety of tasks such as determining where the audit trail is written as well as the level of detail you would like to capture when auditing. And if you want to take the auditing concept to the next level of sophistication, I suggest you brush up on Oracle’s fine-grained auditing (not to be confused with fine-grained access control).

Number 2: Database-side security. When building applications, Oracle 11g provides a lot of flexibility in terms of how you are going to implement security. One option is to handle all of the security in the code of the application, and pretty much ignore the security set up in the database. When that application needs to finally access the database, it makes a connection as a highly privileged user who can do almost anything in the database. But since any user would have to go through the application to get to the database, the application restricts that user to just those database activities that the application deemed appropriate for that type of user.

On the other hand, you could take advantage of all the features of the database to rely on securing the data. This, IMHO, is the better way to go because you aren’t recreating all of the logic that the database already has built in through privileges, roles, virtual private database, and so on. Also, if you don’t rely on the database to perform your security checking, every new application is going to have to be built with all of that logic repeated each time. It’s also very helpful to the developer to use application roles. These can either be default roles that the user acquires at logon, or roles that the user (or the code the user is running) must explicitly request.

For an extra layer of security, you can attach a password with those roles. The user can be prompted for that password as part of the running application. You also have the ability to turn the role on at one point in your code, and then turn it off at another point in your code. The net effect is that the user will only have the privileges contained within that role for the short period of time in the code while the role is turned on. This provides the developer with a whole slew of options in terms of developing highly secure applications.

Number 1: Password customization. My favorite security feature in Oracle 11g is the ability to create your own logic to determine what is and what is not considered to be an acceptable password. If the DBA knows a little PL/SQL, she or he can create some pretty creative rules for users who are attempting to change their password. This feature is implemented by a function you create and name and then assign to a profile. The return value for your function will be a Boolean. If FunctionA is the password function associated with the profile DEFAULT, then any time a user with the DEFAULT profile tries to create or modify a password (for themselves or for others), then FunctionA will automatically run. If that function returns a TRUE, the new password is considered acceptable by Oracle (assuming it’s not violating some other requirement). If that function returns a FALSE, the new password is considered unacceptable by Oracle and the password is NOT changed.

There are three input arguments to the function and their values are automatically populated by the Oracle software. They are the username, new password, and old password of the user whose password is being assigned with the creation of a new account, or whose password is being changed with an existing account. What the function does with those three values, and whether the function returns a TRUE or FALSE, is strictly determined by the logic implemented by the author of the function (you!). For example, since you have access to the values of both new and the old passwords in your code, you could very easily compare them, and based upon whether they were identical, return either a true or false. You could also very easily look at the number of characters in the new password, and if it’s not long enough in your opinion, you could prevent the user from changing it. You can access SYSDATE and prohibit password changes on certain dates or during certain time frames. All of the examples I’ve given could be done with less than a half dozen lines of PL/SQL code. If you want to go crazy, your rule regarding acceptable passwords is only limited by your creativity as a programmer!

Until next time, be secure!

Bob (orcltestguy)

Blog at WordPress.com.
Entries and comments feeds.

%d bloggers like this: