Believe it or not there are still companies emailing users with plaintext passwords. Worse yet, some systems are storing plaintext passwords in the database. Storing or emailing plaintext passwords can increase security vulnerabilities by as much as 10x.
CU Boulder, a premier university, still emails their passwords in plaintext. Regardless of how complex a password is, if it is stored or emailed in plaintext, that password is easily accessible to anyone and security is compromised at a glance.
Bottom line. Do not store or email your passwords in plaintext. It’s a horrible idea. Here’s why:
Storing plaintext passwords
- If the database is compromised, the hacker now has access to everyone’s password. That means people who use the same password across sites are in jeopardy of having their bank accounts drained or their identities stolen.
- If there are vulnerabilities that would allow SQL injection, hackers don’t even need access to the database server to get passwords.
- Database backups are also vulnerable. A hacker can now attack a backup server and get access to passwords.
Emailing plaintext passwords
- Emails can be forwarded accidentally. This could mean a password might be leaked by a user that mistakenly forwards the email to their team or the whole company.
- Some email servers aren’t secure. Emails are stored plaintext on most email servers, so if a hacker gets access to the server, they can just run a script against the email database and find plaintext passwords.
- Emails aren’t always encrypted on the wire (when they are sent from your computer to the SMTP server or between SMTP relays). A simple packet sniffer can intercept emails and be trained to look for plaintext passwords. If you are sending emails from a hosting provider that supports multiple companies (like AWS or Rackspace), a hacker can put a packet sniffer on the same network and read your emails.
- Emails aren’t a direct communication. Emails bounce between servers on their way from your outbox to someone’s inbox. Emails are rarely encrypted and therefore might be intercepted as they bounce around and are easily readable by a machine.
- Strong encryptions. Passwords should always be hashed using a strong, one-way hash algorithm. In addition to using a hashing algorithm, you should also be salting the password and performing multiple hash passes. This will prevent brute force or lookup attacks on passwords. In the event that the user database is compromised, it will still be nearly impossible to reverse engineer a user password from the stored hash.
- Verification ID. Never email a plaintext password. If a user forgets or needs to change their password, send a link (with a random verification ID) that allows the user to securely change their password within a set time period. The company should never know the user’s password.
- Multi-factor authentication. If the above fail and the password has been compromised, using MFA or 2FA keeps the user account secure. Two-factor authentication enhances user login security by requiring something the user knows (password) with something the user possesses (their cellphone for example).
- Password invitations. If you are manually creating user accounts and need users to set their own passwords, avoid sending a random or temporary password via email. Instead send the user an email or push notification allowing them to set the password themselves.
Inversoft is a security company, focusing on identity and user management. Our product, Passport ships with code based 2FA, brute force login detection, password hashing, forgot password, email templates and more. See our free Guide to User Data Security for more suggestions on Password Security.
Stormpath customers are experiencing first hand the repercussions of using a multi-tenant cloud hosted API. The company was acquired and users have to get data out, fast. By 8/17/2017 to be exact.
A recent article by ProgrammableWeb discusses the dangers of using third-party APIs, however they fail to mention ways to avoid this danger. The answer is not to stop using cloud APIs, nor is it to only select API’s from tech giants like Amazon, Google or Microsoft. Before choosing your identity and user management provider consider the deployment options.
Despite increasing cloud popularity, many companies still prefer (or require) an on-premise solutions.
Certain organizations face regulatory requirements that demand an on-premise solution. Regulatory controls and legal requirements vary depending on the industry, but many companies fall into this category. A third-party cloud vendor may not fit the compliance requirements for a particular organization within the finance or pharmaceutical sector.
An on-premise solution can insulate you from issues Stormpath customers are now faced with. By installing the software on your servers (real or cloud-based) you gain control over:
- User data
If the company shuts down or is acquired, you can likely continue using software since it is running on your servers. If this is not the case, the user data is yours and can easily be removed at your discretion.
How do you protect your data? How do you ensure that you are the only one seeing your user data?
Multi-Tenant vs. Single-Tenant
Multi-tenant is an architecture where multiple companies store their data within the same instance. With single-tenant, each company has their own individual instance. With a single-tenant solution you receive maximum privacy. The risk of another business accidentally receiving data that doesn’t belong to them is eliminated. Each customer’s user data is separate and secure.
When considering cloud solutions, it is always important to prepare for the worst-case scenario. You should think about how you will get your data out of the cloud, before you ever put it in there. In the event of an API shutdown, data recovery is much easier when each customer’s data is isolated in a single-tenant cloud.
Flexible Hosting (with a pitch)
Passport offers on-premise or single tenant cloud hosting. With these options, you have the ability to choose which deployment best meets your business or application needs. In addition, you have the flexibility to change your mind down the road.
Start Migrating from Stormpath to Passport today. Or sign up for a free Passport trial.
What we know
Stormpath has been acquired by Okta.
- The Stormpath APIs will remain in service until August 17, 2017 at noon PST. On that date and time, Stormpath APIs will be shut down.
- The Stormpath SDKs will be in maintenance mode until August 17, 2017 when they will be decommissioned.
- Stormpath users will be able to migrate their data into Okta, and may also export their Stormpath data to use as desired.
Current Stormpath users must migrate – whether it be to Okta or a different provider altogether. We understand this is a challenge, a challenge you most likely did not see coming in the near future.
You have 6 months to choose a provider that best meets your business needs, export existing users and be up and running with minimal end user disruption. We are here to help. Continue reading
If you have been on the internet this week you are aware of the fake news crisis spiralling out of control. But just in case you missed it, recent headlines read something like this: Facebook is being blamed for Trump’s election, Google and Facebook Take Aim at Fake News Sites, Facebook’s fake news crisis deepens.
With great power comes great responsibility
Facebook has over 1 billion active users who utilize the platform to post, share and comment on news. When Facebook was accused of influencing the election, Zuckerberg was quick to say that was a “pretty crazy idea.” Is it really that crazy? Facebook has become a catalyst for the spread of fake news given the ease of it’s “share” button. Regardless, fake news isn’t going away anytime soon, it will likely worsen and while Facebook has taken steps to limit the sites’ use of their ad networks, there has been no push to eliminate fake news from the News Feed.
This daunting issue is not Facebook’s alone. Any platform that allows user generated content would be wise to get out ahead of this growing problem in order to prevent this spam and protect their brand. Continue reading
CleanSpeak can filter many types of user-generated content (e.g., chat messages, forum posts and reviews). Running this material through CleanSpeak on a “per message” basis ensures each piece of content is acceptable before allowing it to be seen in your community. Filtering by message makes sense for these specific use cases. But what if you have big data that you want to filter as a whole?
According to Wikipedia, Batch processing is the execution of a series of jobs in a program on a computer without manual intervention (non-interactive). Strictly speaking, it is a processing mode: the execution of a series of programs each on a set or “batch” of inputs, rather than a single input (which would instead be a custom job).
So when might you consider batch processing?
Maybe you purchased a list of names & addresses and want to make sure they don’t contain any vulgar language before including them in your marketing campaign?
Perhaps you allow users to upload files and want to make sure they don’t contain inappropriate content?
Or you gather a list of reviews and want to check them all at once to ensure the language is acceptable before posting to your site?