Forgot my password and spam

On the topic this month about security and password, the discussion of lost passwords come to mind today. When you need to reset your password on your website, the most common thing it asks you for is your password.

pass1

Seems simple and harmless enough, but can it be a gateway for spam? You might thing not, but depending on how the website responds to the email address you put in, it might!

Some systems will reply in a clear way on if that account exists or not. For example, it might reply that the password will be emailed to you, or that the account doesn’t exist.

Think about that, what is the implication?

Simply that a malicious person can write a very basic script that will attempt to “password reset” random email addresses, and your response will verify if that email actually exists.

The threat here is a couple:

  1. First it gives a hacker specific knowledge that your account exists so it can try to brute force their way into your account;
  2. Instead of attempting to figure out your account, now I can simply send you a spoofed email saying you need to change your password at your-bank.com because, well I know you have an account there and it makes the attack that much more legitimate-sounding;
  3. Finally, it lets them sell your email address as a known good address, since obviously, you use it to access some online service.

 

For the end-user/consumer/professional, take a moment, see which websites leak your private email address. If they do, direct them to read this article so they can protect your privacy better.

For developers, this is a call to action to stop leaking this data accidentally. The preferred method is to simply say “if your account exists, we’ll send you a reset password”. That stops it dead in its tracks because that message goes to every email attempt. Also, be sure to check out this article about account security overall.

 

WebDev: Password Best Practice

Based on my article earlier today about Password Reset Tips for Businesses, this article is about the responsibilities and best practices of web developers. The Security versus Convenience paradigm is well known. There is no specific rule here because each business use case is different. However, it is extremely common for security to be an after-thought or bolt-on instead of designed with a security model in mind.

It is important to first determine what level of security is needed. And while most of us are not designing a bank-level secure application, we often have extremely valuable and sensitive information. Among those is the simple username-password combination. We all know someone who does it, perhaps you still do, but almost certainly you used to — that is share passwords between websites. And your application users are doing that too. Many of them actually are giving you their bank password! So to some degree, you have extreme trust from your end users and need to take that seriously. So with that in mind, let’s talk about several best practices as well as what I’ve seen in the wild:

  • Passwords:
    • should never be stored in plain text or even in an encrypted form. In virtually NO use cases it there a need for you to know their password.
    • any password sent in plain text should be a one-time use password (ie initial email, or password recovery). A password reset that is sent via plaintext email should never be reusable.
    • the hashing algorithm should be upgradable because today’s secure hashes are yesterdays insecure. I remember when MD5 was the best hash we had available. Your code should be able to accommodate changes to the hash method.
    • passwords should be salted. Some frameworks like PHP password_hash provide unique, one time salt for each hash.
    • password length and other criteria should be determined by your specific need for security – obviously the longer the better. In fact, everything supports that length trumps complexity every time. The NIST even removed their recommendation for special characters.
    • consider partnering with third parties like LastPass to help users adopt using a password manager.
    • consider checking all passwords against the list of 500 million breached passwords via API.
    • know that single-use passwords aren’t more secure. That is the practice of simply emailing or texting a user a password at each login.
    • while password expiry in the sense of scheduled password resets is considered legacy practices, consider when passwords should be no longer valid. Imagine that inactive accounts (say 1 year) have their password hashes purged. Thereby requiring the user to reset their password via email. How have you improved security? If you were breached, how many fewer passwords would be exposed? Think of Linked in being able to say instead of 167 Million accounts compromised, they could say 30 million active accounts were compromised. (and 137 usernames without passwords). That would be a huge improvement. It helps the security landscape, but still might not save your job!
  • Usernames:
    • email accounts are okay, but usernames are better. They tend to be even more unique.
    • consider providing “display names” and “usernames” as distinct fields. The username then can be hashed for additional security just like passwords. In the event, your database is exposed, both the username and passwords are protected. Ideally using a different salt then the passwords.
  • Email Addresses:
    • evaluate: do you really need to know the email address for your users? In many cases, the only time you contact them is during a password reset, during which they can provide you the email address and you can compare it to your hashed value.
    • some other uses have been that a user preference in another table stores things such as user notification settings (phone, email, etc). So that notifications can still be sent out, while keeping your authentication database table free from unsecured email addresses.
  • Two Factor Authentication:
    • these are great technologies to employ for either each login or for when accessing highly sensitive areas. My bank, for example, requires my use of the RSA-2FA Fob when I conduct any financial transfers, but just a simple password for most “less sensitive” activities. This is a great balance of security/convenience.
    • my own personal perspective is that biometrics-based authentication must always be paired with another factor and never relied upon as a single factor. (ahem, Microsoft) While password management is an issue, the problem with biometrics is that we’re barely keeping ahead of the ability to detect fraudulent use of our biometric data. And the biggest problem is once your biometric identity has been compromised, you cannot change it like you can a password. Once fingerprint tables get into the wild (perhaps they already are), you cannot just change your biometric data. You have to trust that they biometric technology gets better to detect fraud.
  • Cookie & Session Security:
    • this is huge and cannot be simply stated, but you must not blindly trust your web server to security handle session state. You must ensure that the person you think you’re talking to is the right person – that the session hasn’t been hijacked.
    • consider limiting the number of sessions per login (that is that two sessions cannot simultaneously be going on with the same credentials).
    • understand how roaming IP addresses impacts sessions (cell phone roaming, etc). When might you need to prompt for authentication?
    • clearly understand how your “remember me” can be insecure, and what actions might trigger a re-authentication.
    • is there a way for users to manage and understand their active sessions? Can they flush all other sessions? Should you be doing this automatically?
  • Rate limits, brute force attacks:
    • how is your system designed to detect and prevent brute force attacks? Do you even know if this is happening? I can guarantee that it is happening right now, but can you see it? What are you doing about it?
  • Web Application Firewall (WAF):
    • are you implementing a WAF in your firewall or software based solution? What is looking for zero-day exploits? Protecting against common threat vectors? Protecting about unexpected crashes or code dumps to the screen?
  • Cross-Site Scripting (XSS) & Cross-Site Request Forgery (CSRF):
    • what is being done in code to protect against these threats? Are you just accepting form data without any token?
    • how are you protecting against reply attacks?
    • a major airline made this mistake causing credit cards to be compromised.
  • Zero trust user-submitted data
    • be sure to apply the correct filters to all user-supplied input
    • properly prepare your data before submitting it to your databases to avoid SQL Injection Attacks.

Finally, remember that username/passwords and the issues addressed above are primarily your “front door”. But don’t forget the other security elements that you need to account for. Are the windows, crawlspaces, and inside secure? There is a great YouTube video about physical security for server rooms — you can spend huge amounts on ‘security’ while effectively leaving the physical door unlocked! This includes your physical servers, data-secure-at-rest, data security across sessions, and how data is protected against authorized users. Who can access sensitive or encrypted data? Your server administrators don’t need to be able to see/read/decrypt that data, nor should your web developers.

As you take a look at this, understand that there is a lot more at hand to securely developing applications. If you’re tempted to just hand off this responsibility to 0Auth or another third party, you still need to understand this list. Why? Because you need to know what parts above are handled by them, and thereby know what is on your shoulders. If your database queries aren’t properly prepared, I can still just inject code to “SELECT * from credit_cards WHERE 1=1” and all is lost! That isn’t a authentication issues, but is a security issue. Often we think of security as just been an authentication question, but it goes hand-in-hand with authentication, and it is wholistic, not just something a plug-in, add-on, or module will solve.

 

Happy coding!

Password Tips for Businesses

This year Microsoft made a very public statement about how they’re fundamentally changing how passwords will work in Microsoft Windows 10 moving forward. Most significant is that they’re dropping the password expiration recommendation. This brings their recommended policies closer to what NIST also published on this topic. On one hand, these bring a collective sigh of relief from many end-users who are vexed when they see the dreaded “you must change your password in 14 days”…13 days…11 days… This was previously seen as ‘low hanging fruit’ for any IT consultant to come in and perform a security audit, and point out that they don’t force their users to change their passwords.

There are many reasons for the change in direction for both Microsoft and NIST recently. But the biggest reason I propose is that security threats to passwords have fundamentally changed in recent years, compared to the past. There is a good chance your email account is already known by hackers. But moreover, your password is even known by them. As of today over half-a-billion unique passwords have been compromised. And the ability to hack or compromise a password is far easier then it ever has been.

What the biggest things these shifts by Microsoft and NIST demonstrate are that ‘good enough’ approaches to security simply isn’t. Arbitrarity forcing users to change their passwords doesn’t make them more or less secure. And it has been argued that it often makes it less secure as users work harder to find ways to remember their passwords. Is ‘Th0rsHammer2’ any more secure than ‘Th0rsHammer1’? Likely not, but research consistently shows that is exactly what happens. Let’s step back and understand why we even consider changing passwords frequently. The fundamental reason is that the password becomes exposed, known to bad actors. The theory used to be that it was unlikely, but just in case, if we change passwords frequently it will reduce the impact. Nowadays we know better, it isn’t a question of “if” but when. And the follow-up question is, once your password is compromised, how long do the bad-guys need? Even the halflife of the typical 90-day forced password change is 45-days, more than enough to do damage.

The new model focuses on two elements:

  1. End-user education: Which primarily focuses on identifying threat vectors such as phishing attempts. But also in how to choose a good password, and avoid password reuse.
  2. Detection of compromise: This one is more technologically involved, but it basically required advanced threat detection to identify potentially compromised accounts or servers, and then using that to force a password change.

 

Recommended Action Items for SOHO (Small Office, Home Office)

  1. End-user education: Ensure that end-users receive training on how to identify and avoid phishing emails, how to choose a good password, and that business and personal passwords should never be the same.
  2. Ensure that every computer has a password required to log in — no accounts should be password exempt.
  3. Consider using a password manager like LastPass which will help create and manage your passwords. That way you can have unique passwords for every account.
  4. Consider using a Two-Factor Authentication (2FA) system whenever possible such as Microsoft Authenticator.
  5. Use OpenDNS which provides a basic level of threat protection for employee website activity.
  6. Pay attention to data breaches of large companies. Consider forcing password resets when such event occurs because there is a high likelihood your users are sharing the password between such large companies (LinkedIn, Yahoo, etc), and your network.

Recommended Action Items for Small Business (10-50 employees)

  1. End-user education: Ensure that end-users receive training on how to identify and avoid phishing emails, how to choose a good password, and that business and personal passwords should never be the same. Train on using password managers instead of sticky notes or excel files with password plainly documented.
  2. All systems should be domain-joined with password policies in place, ensuring that all accounts have strong and long passwords. Remove your password reset policy.
  3. Audit your existing use of role accounts, automatic login accounts, shared accounts, etc. Whenever possible eliminate such accounts so there is a one-to-one audit trail back to a specific user. When role or shared accounts are needed, they should generally have far fewer rights than normal users, and policies need to be in place to reset this upon any employee change.
  4. Consider using a password manager like LastPass which will help create and manage your passwords. That way you can have unique passwords for every account. Professional versions permit the ability to share passwords when needed.
  5. Consider using a Two-Factor Authentication (2FA) system whenever possible such as Microsoft Azure AD MultiFactor Authentication.
  6. Use OpenDNS which provides a basic level of threat protection for employee website activity.
  7. Pay attention to data breaches of large companies. Consider forcing password resets when such events occurs because there is a high likelihood your users are sharing the password between such large companies (LinkedIn, Yahoo, etc), and your network.

 

Recommended Action Items for Medium Business (51+ employees)

  1. All the items listed for Small Business PLUS:
  2. Ensure all public facing website exposing corporate resources (webmail, website, extranet, client-portals, etc) implement technologies like WAF, Fail2Ban, and more. Those resources should be placed in your DMZ, which is isolated from your local network and use completely different administrative credentials.
  3. Outbound traffic filtering including DLP (Data Loss Prevention), Advanced Threat Protection and Content Filtering.
  4. Consider implementing password auditing tools which compare your network passwords against the known password breaches.

 

The above lists are based purely on the topic of password-related security, and there are many additional security matters in general which need to be professionally assessed by any business. 

 

 

 

Hashed Passwords

Something making a lot of news in the papers recently is compromised usernames and passwords. This has been seen from companies such as LinkedIn, Yahoo and DropBox. In some of these cases they are storing passwords unencrypted, so that once someone captures the data, they know you actual password. And since many people share passwords among accounts (using the same password for LinkedIn and Facebook) it opens your account to be compromised on multiple systems. This is made worse when more sensitive logins, for back accounts or your work e-mail is the same password you used on Facebook.

One common technology used by web developers and programmers in general is to NOT store your actual password but rather to use a hashed version of your password. Hashing is a form of one-way encryption where once has been hashed it cannot be reversed out (hence the one way part). It also is specifically designed so that there is no two inputs which can create the same output. In fact, even a single character difference usually results in radically different outputs. So this often used so that nobody, not even the database needs to know your real password. All that they do is when you enter your password at login, it will run the password through the same hashing algorithm and then make sure the output matches what is stored in the database for your password.

To make this more secure, many web developers will also add “salt” to the hashing process. That is, they add some extra information to your input before it is hashed. Then benefit of this is that as long as the salt is kept secret, it makes it significantly more difficult for your actual password to be discovered.

What brings this to mind was something I recently encountered today. I forgot the password for a specific online portal that I rarely use, and since I never document passwords, it is really all left up to my memory to recall. Typically when you go to a website and click “forgot password” they will e-mail you a new password or a link to create a new password. However in this case, they e-mailed me my password. What this illustrates to me is that they don’t actually hash their passwords, and don’t likely encrypt them either. With this, I can know, for certain, that it is possible for someone at that company (or someone with malicious intent) can access my passwords. This is very concerning.

In the day that we live in, it is very important that we ask our vendors to be using more secure methods for storing our passwords. If they can tell us what our passwords are, this is concerning.

Also, since we cannot always force a vendor to do something, please remember to be vigilant in how you handle passwords. Avoid using the same passwords online, and ensure that you are changing them periodically. If one of the services you use (such as LinkedIn) has a data breach, be sure to change all passwords for places which you used that password at.

Enjoy!

Offline NT Password & Registry Editor

What is it?

  • This is a utility to reset the password of any user that has a valid (local) account on your Windows NT/2k/XP/Vista/Win7 etc system.
  • You do not need to know the old password to set a new one.
  • It works offline, that is, you have to shutdown your computer and boot off a floppydisk or CD or another system.
  • Will detect and offer to unlock locked or disabled out user accounts!
  • There is also a registry editor and other registry utilities that works under linux/unix, and can be used for other things than password editing.
  •  

Continue reading “Offline NT Password & Registry Editor”

Technology Policies/User Passwords

It is the general policy that the IT staff does not need to know the individual user passwords and will take every effort to ensure that we do not keep this information. As a result, whenever we need access to a users account, we will generally choose one of two options:

  1. Have the user (if available) enter in their password; or
  2. Change their password on the server, and when completed, set the password to “require change on reboot”.

It is important that after a users password has been reset, that the following process be followed to notify them of their new password:

  • A note (preferably type written) explaining that work has been completed on their system and to check their voicemail for their new password.
  • On their voicemail, leave them their password (repeat slowly twice) and inform them that they will be prompted to change it when they next log on. Additionally, if they have questions to contact the office.

Recovery procedure to recover from a lost Password or User Name for an APC UPS

Recovery procedure to recover from a lost Password or User Name for an APC UPS system

1. Select a serial port at the computer to be used for a terminal-emulation connection with the Management Card.

2. Disable any service that currently uses the selected serial port, such as PowerChute plus or UNIX Respond.

3. Disconnect any cable from the selected serial port and connect the smart-signaling cable (940-0024) that came with the Management Card to the selected serial port and to the serial port on the UPS or chassis.
Note: If the computer uses smart-signaling PowerChute plus, omit Step 3: A smart-signaling cable (940-0024 or 940-1524) is already installed.

4. Run a terminal program (such as HyperTerminal).

5. Configure the serial port for 2400 bps, 8 data bits, no parity, 1 stop bit, and no flow control, and save the changes.

6. Press ENTER to display the User Name prompt (you may need to press ENTER two or three times).

7. Press the reset button on the Management Card.
(This will reboot the card but will not reboot the UPS.)
***For cards with the most recent firmware (2.5.0 or higher), you will need to press the reset button an additional time.
Once the status light on the card starts flashing rapidly between orange and green, press the reset button again.
You will see the light on the card go off for roughly 30-45 seconds. Once the light comes on, proceed to step 8.***

8. Press ENTER to redisplay the User Name prompt.

9. Use apc for both the User Name and Password to log in.
Note: If you take longer than 30 seconds to log in, you will need to repeat Step 6 through Step 8.

10. Select System from the Control Console menu.

11. Select User Manager from the System menu.

12. Select Administrator from the User Manager menu, and follow the on-screen instructions to change the User Name
and Password settings to the new values.
***Please note that your password is only limited to 10 characters or less.***

13. Escape out to the main menu

14. Log out (4) to save the changes.

15. If necessary, reconnect any cable disconnected from the computer’s serial port in Step 3.

16. Restart any service disabled in Step 2.

Microsoft Strong Passwords

Just a reminder about passwords for clients where we have enabled “Passwords must meet complexity requirements”. I received a call today from another tech needing help, and here are the specific criteria:

When this setting is enabled user passwords will have the following requirements:

• The password is at least six characters long.

• The password contains characters from three of the following five categories: English uppercase characters (A ” Z); English lowercase characters (a ” z); base 10 digits (0 ” 9); non ” alphanumeric (For example: !, $, #, or %); Unicode characters.

• The password does not contain three or more characters from the user’s account name. If the account name is less than three characters long then this check is not performed because the rate at which passwords would be rejected would be too high. When checking against the user’s full name several characters are treated as delimiters that separate the name into individual tokens: commas, periods, dashes/hyphens, underscores, spaces, pound-signs and tabs. For each token that is three or more characters long, that token is searched for in the password, and if it is present, the password change is rejected. For example, the name “Erin M. Hagens” would be split into three tokens: “Erin,” “M,” and “Hagens.” Since the second token is only one character long it would be ignored. Therefore, this user could not have a password that included either “erin” or “hagens” as a substring anywhere in the password. All of these checks are case insensitive.

In this specific instance, the problem was that the user was trying to use part of their name in their password.

Checking for strength:

Continue reading “Microsoft Strong Passwords”

Powered by WordPress.com.

Up ↑