To main heading

Smallsite Design

Online management help

3  Security and passwords

Some explanations of how security and passwords are handled in Smallsite Design.


Before going into the details of the password scheme employed by Smallsite Design, some perspective on how likely a site built with it is to be attacked.

Smallsite Design is for the construction of passive publicly available information. General users of the site are there only to read and none of their private information is collected. The security is to prevent unwanted access to the site management which could be used to deface or destroy the site. The users who can log in are there to directly contribute future public content for the specific articles specified by the site owner for the duration needed.

Smallsite Design is expected to be run on shared hosting, though it could be run on privately-owned servers as long as they run the supporting software stack. Such hosting is unlikely to be resilient enough to withstand an attack from well-funded state or criminal organisations, meaning that once they have successfully taken over the machine on which a site runs, they can do whatever they like to the site content.

Unless the content is specifically designed to annoy or challenge those with substantial interests to protect from such attention, a Smallsite Design site is unlikely to be subject to effective malicious attacks as there is no money or secret information to be found. The average information or online help site is unlikely to attract any untoward attention. These are not wikis nor social media sites where users can contribute their own choices of content which might create problems for the site owner, but well-curated content that must be explicitly made public by the owner themselves.

As far as site cybersecurity goes, Smallsite Design sites can expect to get an A+ rating (highest) on Qualys SSL Labs' SSL Server report, meaning that current known server vulnerabilities are mitigated against. Of course, this assumes that the servers and the rest of the software stack that the sites are running on are fully patched and up-to-date, which is up to the hosting provider to maintain.

Passwords are stored salted and hashed, so if the site data is hacked, the passwords themselves are not. Even if the passwords have been used reused elsewhere, the attackers will not have the actual passwords to try them out on those other sites. The hash is recalculated with a new salt at each login. Sessions are protected against cross-site scripting (XSS) by best security practices.

User IDβ–³

User IDs are a shorthand for the user requiring access.

For many systems, user IDs are an email address, which is a personal piece of information that can be used for scamming and harassment. In many organisations, they are derived from a user's full name, and so are not generally considered secure in themselves. Given that, and since a Smallsite Design site is expected to have very few users, the IDs are short and expected to be for users' initials. Users' email addresses are not publicly exposed, nor used for anything but private notification of events requiring attention.


Smallsite Design has some measures to improve the effectiveness of passwords.


Passwords are awkward, especially long ones, so Smallsite Design uses a novel method of helping to remember them.

Smallsite Design requires passwords of 20 to 40 Unicode characters – though plain ASCII is fine – which would normally present a memory challenge.

The idea behind this password regime is that because people like to have a memorable password, but have difficulty remembering a complex one that would be more secure and unguessable, a simple prompt, perhaps the name of a place visited, should be enough to remember a couple of normally insignificant facts about the place, but which nobody else knows about. The prompt can be displayed in public, and no one will have a clue to the password.

The facts can be anything, like the shape of a stain on a wall or something else noticed and remembered, but never told to anybody else. String a couple of those together to get enough characters for a password.

For example, remembering looking out over the Manila sea from the balcony of a 16th floor apartment may give a prompt of Manila and a password of 16thbalconyoverthesea. A postcard of Manila, for somewhere else but the sea, stuck to the computer or as a background picture for a phone, may be all that is required to be the prompt. The prompt is so general that except for the personal but vivid memories, no one else can possibly know what it means and how it relates to the password.

Warning: Do not use a prompt that is directly related to the content of the password, as it must be a very indirect reminder for something obscure that is only known from uniquely personal memories. That means it should not be a synonym for something in the password, nor a clue for an attacker that indicates that something they already know or can find out about has been included in it. It is to be a reminder of the context or location of the memories, not an indicator of the memories themselves.

Sometimes a long password may be awkward to type in for the first time, so after the initial vetting of the password, typing it in four more times gives a chance to get more familiar with the typing rhythm. If it is still too awkward to type in, such as might happen if one word ends with the same character as the first character of the next word, think of another password phrase.


There are over half a billion leaked passwords publicly available as a result of hackers.

Checking of passwords against this password database is enabled by filling in the fields of the Password checking section of the Settings page. By default, the facility is enabled, and the service is provided by the Have I Been Pwned? site run by Troy Hunt. If any of the fields are blank, the checking is not done.

The password checking is done at login, at least 24 hours apart, or when creating a new password. If the check fails at login, a warning notice will be displayed at the top of the page, leaving it to the user to decide when to change their password, though the current master manager is notified. If the test fails when creating a password, an error message is displayed and another password will have to be provided. If the checking service cannot be reached, checking is treated as having passed, so as to not to unnecessarily prevent access.


Smallsite Design uses a fairly simple means of providing 2-factor login, without requiring hardware or intrusive apps.

If 2-factor login is enabled in the Access section of the Settings page, upon login, an email with a special link is sent to the user. Once the link is clicked on, the Work list page is shown, after which the Close me page opened by the link can be closed if it did not close immediately. This process relies for its security upon the email address not being accessible by anyone untrustworthy of having access to the site.

That means that a user should have sole access to a computer or other device that has a browser or password manager that automatically logs into both the Smallsite Design site and their 2-factor email address, which is also where they receive notifications from Smallsite Design.

2-factor login is more secure than passwords alone because it involves two unrelated (known as out-of-band) means of communicating mandatory information required to log in. Many businesses send an SMS to a phone with a code, but because phones have been hijacked by what is know as SIM-jacking, alternatives to SMS have been sought. Note that an email-to-SMS gateway, a separate third-party paid service, can be used to send a link to a phone, but these are unlikely to be used by many individuals or micro-businesses.

While not in the same security league as FIDO2 password-less authentication, this simple 2-factor regime should block the great majority of automated bot and bulk phishing attacks, and the majority of targeted attacks. Preferably use an email address that is not widely distributed or publicly available. The email will come from the noreply account of the site's domain. Only click on a link in an email from that address if attempting to login immediately beforehand.

Many organisations send a numeric code that has to be entered to gain access. That requires more remembering and keyboard entry for essentially no advantage over clicking the link. That is the only link that is ever sent from the site, so its timeliness with the attempted login should be sufficient to indicate that it is a legitimate email from the site, and not a spoofed one, so the link is safe to click.

This regime does not use an authentication app on a phone. While Google's app itself is secure, Google is collecting location and other possibly personally identifiable data from the phone itself which it will bind to information gathered from other sources to build up a detailed personal profile to provide to possibly politically-motivated advertisers so they can track and target the phone owner. If intending to use an authenticator app for other purposes, use one produced by an organisation that does not enable any obtained data to be used directly or indirectly by third parties.

  • β€’Import
  • β€’Work list
  • β€’Files
  • β€’Contact   Glossary   Policies
  • β€’Categories   Feed   Site map

  • This site doesn't store cookies or other files on your device when visiting public pages.
    External sites: Open in a new tab or window, and might store cookies or other files on your device. Visit them at your own risk.
    Powered by: Smallsite Design ©Patanjali Sokaris