Two-Factor Authentication (supposedly patented by Kim DotCom)– using a password plus “something else” to gain access to your account and to prevent lost, stolen, or guessed passwords from impacting you — is finally becoming fashionable.

First, it was a cool idea, then some places such as LuxSci started supporting it, but it was rarely used due to people not wanting to bother with an extra step to login to their accounts.  Now, with Twitter adding 2-factor authentication to help stem the tide of account compromises, security is now fashionable.

This turn about is really fantastic as it brings security consciousness much more into the mainstream — so much so that popular Radio hosts are talking on the air about how to secure accounts.  This can only be good for the adoption of better security practices overall and a decrease in compromises due to laziness … and in cases like HIPAA, laziness can be a terrible thing.

In this post, we’ll go over how to secure your LuxSci account against intrusion using Two Factor authentication and other methods.

Read the rest of this post »

We are frequently asked how to create and manage email distribution lists at LuxSci.

Distribution lists are email addresses, like “allstaff@your-domain.com” that accept inbound email and then forward (distribute) those messages to one or more different email addresses, so that everyone on the list gets a copy of the message.

At LuxSci there are three ways to setup a distribution list, each having its own particular benefits.  These include:

1. Email Aliases distributing to multiple arbitrary addresses
2. Groups of people in your account 
3. Custom rules that forward email only under certain circumstances

LuxSci has re-tooled its email alias management interface from the ground up to make it faster, more powerful, and more consistent with many of its other administrative interfaces.

Email aliases are addresses in your domain that do not correspond to a physical user, but which may deliver email to one or more addresses or deny email with a custom message.  E.g. “sales@yourdomain.com” might not be an actual person — it might just forward email to a few of your employees.  The LuxSci Email Alias Management tools enables administrators to create, edit, and delete these kinds of email flow rules for all email addresses in all domains in their account — Aliases, Domain Catchall Rules, User email forwarding rules, and WebAide User Group mailing list rules — all in once place.

Read the rest of this post »

LuxSci has made two significant improvements to its Account API – one to improve security and one to enable automated management of user AutoResponders.

Read the rest of this post »

We are sometimes asked if there is any way to make SSL and TLS be compatible with each other.  On the surface, this may seem almost nonsensical, but there are cases where such a question actually makes sense!

SSL (Secure Sockets Later) and TLS (Transport Layer Security) are fundamentally the same form of encryption – see SSL versus TLS – what’s the difference. But if that is the case, doesn’t that make them automatically compatible?  Well, not really.

Read the rest of this post »

Email and other data is either being “transmitted” or  ”processed” or “at rest”.  E.g. it is moving from one computer to another, or it is stored / at rest on a computer, or it is preparing to be transmitted or stored.

While most types of compliance regulation, such as HIPAA, specifically require that data be transmitted securely, not all regulations require that data be stored in an encrypted format while at rest.  E.g. HIPAA does not require at rest encryption, though it may be recommended to decrease potential liability.

However, having your email and other data encrypted while at rest does significantly increase the security of that data, even if that level of security is not explicitly required.  As a result, many LuxSci customers have asked about how to ensure that all of their email and other data is encrypted while at rest.

Read the rest of this post »

A majority of companies and hospitals that offer email encryption for HIPAA compliance allow senders to “opt in” to encryption on a message-by-message basis.  E.g. if the user “does nothing special” then the email will be sent in the normal/insecure manner of email in general.  If the sender explicitly checks a box or adds some special content to the body or subject of the message, then it is encrypted and HIPAA compliant.

Opt-in encryption is desirable as it is “easy” … end users don’t want any extra work and don’t want encryption requirements to bog them down, especially if most of their messages do not contain PHI.  It is “good for usability” and thus easy to sell.

However, opt-in encryption has become a very bad idea with the inception of the HIPAA Omnibus rule.  Its use imposes a large amount of risk on an organization, which grows exponentially with the size of the organization.

Read the rest of this post »

We have written extensively in the past about the impact of HIPAA regulations on email services, web hosting, faxing, and Skype use.  The recent HIPAA changes reflected in the Omnibus rule have a significant impact on the use of these types of services.  Here, we examine the new and important considerations based upon the HIPAA Omnibus Rule.

Read the rest of this post »

LuxSci sends many different kinds of automated email messages to users and account administrators.  Some examples include:

• Support Ticket updates
• Alerts of login successes and/or failures
• Spam quarantine reports
• Reports on the failed sending of email messages or spam feedback loops
• Notifications of reaching or exceeding various types of limits
• Status notifications from automated or periodic processes
• many, many more

Until recently, a large majority of these automated email messages were simple “plain text” messages and the ones that were HTML, used very simple, plain markup.

Read the rest of this post »

Since its inception in 1999, LuxSci Support has manually handled all password reset requests that were not handled by the account administrators.  

Why? Security reasons, of course. We are aware of:

• Poor Security Questions: very often users have poorly chosen answers to security questions,
• Hackers: that people often try to use password reset systems to gain unauthorized access to users’ accounts
• Lack of Information: users often do not have enough solid information in their profiles to reliably verify their identities

By manually processing these requests, we can effectively block password resets in the face of poor identity verification information and subjectively identify “fishy” requests.

However, we have come to determine that this manual process, while it provides the best security, is not actually in the best interests of our customers because: