A government agency sent our website admin an email that our website had been defaced We got an official email saying that our website had been hacked. They cited the URL to use to see the new suspicious file that had been dropped in our web root folder (s.htm). Just some text about a "Morrocan Made hacker - I'm Back" in the HTML file. Nothing else seemed damaged although we are investigating.

The link included in the email was exactly hXXp://example.com[.]au/s.htm in plain text, which is also a bit weird, although helped us find the file.

The date stamp on the file is only 7 hours and 3 minutes different to the Sent date on the email. 7 hours could easily be a timezone deviation.

My question is: How did the government agency (CERT) know that our website was hacked? It's an Australian hosted website, for a legitimate business - and the government agency is legitimate.

It's extremely easy to fake email.  If someone did fake this, I don't see how the agency would know about it.  The concern is that the link they sent you was the attack itself.  For example, this could be a CSRF attack:

  With a little help of social engineering (such as sending a link via
  email or chat), an attacker may trick the users of a web application
  into executing actions of the attacker's choosing.

One suggestion is to contact the office and find out if this is something they do.  Just because the language seems right and says it's from the right sender means nothing.  That's a common approach used in phishing emails.


Can we implement custom algorithms to encode and decode wifi password hashes between Windows 10 and our Router? Windows 10 has its own way of encrypting hashes, but these can be brute-forced by hashcat. One of our students created 2 of his own password encryption algorithms in python (One for encode, one for decode). Is there a way we can implement his algorithms on our Windows 10 PC and Router such that the algorithm encodes the wifi password, creates a hash, and then sends it to the pc, which reads the hash and then uses the decode algorithm to get the correct password.

Edit: I read the possible duplicate, but what I'm trying to do here is implement this method of encryption along with standard hash encryption. This algorithm is for string encryption, which would encrypt the password before it becomes a hash. I agree that standard tried and true hash encryption is the safest hash encryption. How do I encrypt the string before it becomes a hash?

Don't create your own custom algorithms. This is a trap that novices fall for again and again and again.

If you do, you will fail, because you are not an expert. Good algorithms are designed by people who spent decades on this very material, and the results again are checked by hundreds of cryptoanalysts, trying to find any imaginable flaw.

Your student, without trying to be personal, does not have this expertise. They are likely not even close. As a result, using your own "custom algorithm" will lead you to getting your connection cracked and highjacked, if anyone would seriously try.

How can we make our Wi-Fi secure?

Use a long passphrase! If brute force is your only worry, then use a long password that make brute force infeasible.

Use a password like .;{mr%chKzc<Z44aZ&+NV&uW!PuA5!CkJLA8*=c546/7'>,;{3@2w4x]9N}f?Da and you will be 100% safe.


Does Injection Attack Against SQL Server Require Semicolon or Comment? In creating a blacklist function as part of our multi-pronged defense against SQL injection that includes parameterized queries and validating for length and type of input, we are creating a Blacklist function to check input from a .Net web form to run against SQL Server.
Does there HAVE to be a semicolon (;) or comment (--, /* */) for a successful SQL injection?

In the fully general case, absolutely not. For example, suppose your login system uses a SQL statement that looks like this: "SELECT TOP(1) userId FROM Users WHERE username = '" + userName + "' AND password = '" + hashedPass + "'" where userName is directly supplied by the user. If the attacker supplies ' OR 1=1 OR 'a'='a - which has no semicolons, comments, or even subqueries - then the entire query will be SELECT TOP(1) userId FROM Users WHERE username = '' OR 1=1 OR 'a'='a' AND password = 'f40a564107bad8ebf1b5ae73c350ebea' (assuming the hashed password is 'f40a564107bad8ebf1b5ae73c350ebea'). The AND operator in the WHERE clause takes precedence, so we gave it a nonsense value to check against ('a' will equal 'a' but the AND will still be false overall for probably every user since the password is a guess, and that's OK), and there probably isn't a username of '' in the DB, but the ... OR 1=1 OR ... part means that every single row will match the WHERE clause. The database will simply return the first row in the table, who is likely an admin of some kind. This example could be modified to instead log in as any specific user, still without needing their password.

As a general rule, while defense-in-depth is good, blocklists are basically worthless. Parameterize your queries (for SQL Server in particular, use Stored Procedures for a perf gain while you're at it) and use database-specific sanitization libraries for anything you can't parameterize or that might otherwise be concatenated into a SQL statement. Where practical, go ahead and validate types and lengths too. Trying to block specific characters is almost certainly going to be either too aggressive (blocking legitimate input) or too permissive (missing something that is potentially harmful) or even both; there is often overlap between "would be dangerous if interpreted as SQL code" and "might legitimately appear in user data".
In the best case, where you somehow have a perfect blocklist that doesn't break anything, it'll still fail if you forget to check input against it. That might sound like a silly concern but both parameterization and escaping are fully-sufficient defenses when used correctly, so for the blocklist to be relevant you'd have to already be forgetting something. Your odds of forgetting every security control except the blocklist seem low enough that its expected value approaches zero anyhow.


Should things that need to be reversed be encrypted? I was told by a friend earlier that

  Encrypting something that needs to be reversed is a bad idea as it gives the illusion of security

Is this true? The way I see it, it can't really hurt to encrypt data.

You should only encrypt things that need to be reversed. If they do not need to be reversed (such as stored passwords), they should be one-way hashed with a secure hashing algorithm.

By definition, something that is encrypted must be able to be decrypted. Therefore, encrypted information is only as secure as the key used to encrypt it.

Key security is the most important aspect of encryption. A strong algorithm with a compromised key is no more secure than plain text.

For encrypting email correspondence, some implementation of PGP (e.g.OpenPGP) is the industry standard:
http://en.wikipedia.org/wiki/Pretty_Good_Privacy#OpenPGP

EDIT: For encrypting files stored locally (such as an email archive), I recommend TrueCrypt:
http://www.truecrypt.org/

Important! Keep in mind that if you forget or lose your encryption key, by design, the encrypted data is completely worthless and unrecoverable. Do not encrypt vital backups unless you are absolutely sure the key will not be lost.


Attacking WPA/WPA2 ; Clarification on deauthentication packets In the attack on WPA/WPA2, one way to force a handshake is by sending deauth packets to force the client to deauntheticate. During reauthentication attempts, the handshake can the be captured. Here is my question: Why is it that multiple reauthentication packets are used? Why isnt one deauthentication packet not enough?

I see on most tutorials the command uses several packets. why not one packet?

Only one four way authentication exchange is required. You can either wait for it or send a single deauth pack to a connected client so that it would re initiate the connection. The reason why they use multiple deauth could be the low SNR of the network. In order to successfully deauthenticate they might need multiple packets as some might get dropped.


Are old Wordpress versions still secure? I checked a Wordpress instances with https://hackertarget.com/wordpress-security-scan/ and it told me that the Wordpress version is 4.7.9 and that I should update. True, current version is 4.9.2, but according to this page:

https://codex.wordpress.org/WordPress_Versions

all branches from 3.7. on have recently been updated (January 16th). So, doesn't that mean that all these versions should be as secure as the newest 4.9.2 ?

I would like to have good arguments convincing webmasters to upgrade their wordpress. I personally would always care for to install the very newest version, but I would like to know what is the actual thread to point it out to lazy webmasters.

For example, what could I tell the webmaster who is still running the 4.7.9 version, what security issues his instance contains, are there any known? Or just potential issues because its so very well supported like the newest version?

In practise yes
There was a XSS bug (XSS vulnerability was discovered in the Flash fallback files in MediaElement), affecting all versions since WordPress 3.7 (at the point where it was discovered, of course).
https://wordpress.org/news/2018/01/wordpress-4-9-2-security-and-maintenance-release/
Wordpress team fixed it, and released version 4.9.2 to fix it on the 4.9 branch. It also released version 4.8.5, 4.7.9, 4.6.10, 4.5.13, 4.4.14, 4.3.15, 4.2.19, 4.1.22, 4.0.22, 3.9.23, 3.8.25 and 3.7.25 to fix the respective branches.
You can easily view the changes and see that they are backports covering this same issue.
So, as far as you update to a newer release of those "old versions", you would be fine... if there are patches.
Now, what you need is to stay at a version for which someone (preferably Wordpress team) will issue a fix if there a new vulnerability affecting it was discovered. This is documented on
https://codex.wordpress.org/Supported_Versions
And there they say:

The only current officially supported version is WordPress 4.9.1. Previous major releases before this may or may not get security updates as serious exploits are discovered.
Support Policy
WordPress will be backported security updates when possible, but there are no guarantee and no timeframe for older releases. There are no fixed period of support nor Long Term Support (LTS) version such as Ubuntu's. None of these are safe to use, except the latest series, which is actively maintained.

So, they give no warranties that they will continue doing so in the future, but are fixing the security bugs (no new features, of course). Regarding version 4.7.9 note that Debian stable wordpress package also uses the 4.7 series and this branch is likely to continue receiving security fixes (by both wordpress team and downstream maintainers) for quite a long time.
Given this, I wouldn't consider requiring that the webmaster updates to 4.9.2 if they are already at 4.7.9, as the security issues have been fixed. They are updating their wordpress. The lazy webmasters are those that installed 4.3.5, and are still running that version.


VPN doesn't function properly on google websites Why do google sites display content in my original country's language even if i'm connected to the internet through a VPN?

For exapmple: google.com and youtube displays content in my actual language, maps.google initiates near my hometown.
Browsing msn.com though, redirects to the VPN's country.

I setup a VPN (unblockr.net) connection on my computer that is running an Ubuntu operating system. I am also using firefox. I have tested if my ip changes and it does, so the VPN works but not on google.

Is there some information saved on my system that google can access ?
I removed all cookies,history,bookmarks and reinstalled firefox and even changed my date and time settings on my desktop.

I strongly suspect that the VPN is working but you're leaking information in another way. Some things to try are:

Turn off location services on your computer
Use incognito mode
Disable all browser extensions in incognito mode (I think this isn't the default in Firefox)
Make sure you're not leaking data via WebRTC
Don't login to Google (or any other sites)
Flush your DNS cache in case you are pointing to a region-specific IP address of Google

If this still doesn't work, visit browser fingerprinting sites such as Panopticlick to see if they provide you with any hints.

Update: Perhaps Google is not actually detecting your location, but is instead getting an Accept-Language header from your browser. See what happens if you do the above and set your browser's language preference to English.


Strong unique passwords and TOTP 2FA So I use a password manager with to generate a (strong) unique password for each and every site I have a username / password for.

For the ones that allow it I also enable TOTP (Time-based One-Time Password) 2TF.

This got me thinking.

Theoretically the only way somebody would get their hands on my password (excluding MTM attacks) would be for the password table of the site I'm using to leak, at which point in time the TOTP seed would leak too.

So what exactly is TOTP supposed to be protecting against? Is it intended as a protection against: MTM, key logger, over-the shoulder viewer?

Two factor authentication cannot protect you from a site breach. If someone gains access to the sites password database odds are they have access to any confidential data on that site too.

Two factor authentication protects you from somebody else obtaining your password. If you view this as impossible 2FA is unnecessary. With most TOTP systems this relies on you having possession of a device with the relevant key installed as well as the password to log in. Often this device is separate to the device used to access the service (i.e. a smartphone for the token generator and a laptop for the service) which also offers some protection (your session can still be hijacked) should the device logging in from or your password manager be compromised.

The main risk for yourself is probably the password manager. Vulnerabilities do occur in these. This becomes twice as important if the passwords are stored online - since they are visible to machines you do not control.


Is this ASP site vulnerable to XSS or not? I took a scan of a ASP site and it said that request validation was off. It caught it by sending a URL of example.com/?foo=<script> and received a response URL of example.com/?foo=<script> (Same one).

I took a look myself, and tried to see what was up. I took a closer look at the source code and saw this below the title tags:

<form name="frm" method="post" action="/default.aspx" id="frm" enctype="multipart/form-data">

When I try the URL that the scanner suggested, the source code changes to this:

<form name="Form" method="post" action="/default.aspx?bar=%3Cscript%3E" id="Form" enctype="multipart/form-data">

which is clearly encoded.

Does this mean that the webapp is protected from XSS, and the scanner found a false-positive?

The encoding that is happening is URL encoding ("<" is encoded to "%3C" and so on). This is done by the browser when you type special characters in the URL.

This can be verified by intercepting the request going from the browser to the server using a proxy like Burp Suite.

Now, if you add your script in Burp instead of the browser, the script will certainly reflect back in the response without encoding. The same can be achieved by manually crafting a HTML page to fire the request.

The actual mitigation you are looking at is proper HTML encoding (&lt; and &gt; for "<" and ">"). In order to completely make your application armoured and protected against XSS, I would recommend using the ASP.NET's ValidateRequest filter along with a custom application-wide filter which encodes special characters in all requests.

The application should not accept any script, special character or HTML in fields whenever not required. It should escape special characters that may prove to be harmful. The characters can be escaped as per the list available at this link:

TheUKWebDesignCompany.com, HTML Escape Characters: Complete List


Is signing safe from brute force attacks? I am using itsdangerous to sign a string using a secret key. It says that the signing mechanism is HMAC and SHA1 and that it is an implementation of the Django signing module.

Assuming I use one secret key to sign many strings, and an attacker gets ahold of the full signature my string.wh6tMHxLgJqB6oY1uT73iMlyrOA (including the "my string" portion), how easy would it be for the attacker to brute force this and gain control of my secret key?

I assume the attacker could guess that I'm using itsdangerous and could spend money to provision a bunch of cloud servers.

Is this something I should be worried about?

From a short look at the module it is using a plain HMAC together with SHA-1 (or SHA-512 in newer versions). This is the same algorithm as used in TLS to detect data manipulation.

But a HMAC can be computed fast. The major costs in the HMAC are the hash computation (i.e. SHA-1 in your case) which is needed twice. This means that if you have a weak secret a brute-force attack is possible. And, while Signer seems to offer the use of a key derivation function to "harden" the key the offered functions are only a single hash or a HMAC (i.e. two hashes), which don't really slow down a brute-force attack.

This means that the security of this approach lies in choosing a good secret key, i.e. some long random string instead of a comparable short password. Unfortunately the documentation does not really show what keys are secure and only makes some recommendations similar to password recommendations:

  Given a key only you know ... So if you keep the key secret and complex, you will be fine.

But from similar password recommendations we all know how secure such keys will be at the end. What you really should use is hidden in the source code in the documentation of derive_key:

  def derive_key(self):
          ...
          Keep in mind that the key derivation in itsdangerous is not intended
          to be used as a security method to make a complex key out of a short
          password.  Instead you should use large random secret keys.

The following would create a secret with 128 random bits which is sufficiently secure against brute-force attacks:

 import os
 secret_key = os.urandom(16)


How secure are Google (Drive) Web Forms? My child's school is using a Google Web Form to collect student and parent information, including occupations, addresses, maiden name, birthdays, contact information, and who the child resides with.

How do I know how secure my information is, if I choose to fill it out?

Assuming the school has a valid need for this information, and you are happy to provide it, this is probably one of the better ways to collect it. Compared it to asking for this via email, or paper form that then gets entered into a school computing system. Email is sent in clear text, anyone sharing the same network can see this traffic, including your ISP and the schools ISP. A paper form could get lost on the way to school or in the post, and once entered into the computer probably will get put in the rubbish, not shredded.

Googles servers themselves are very secure, the web forms are also very secure. I would be much more worried about the schools information security, irrespective of how it is collected.
The following are the questions you should be asking the school.

Why are they collecting this information and what use will it be put to?
Who have they given permission to view this information?
Do they require all those people to have two factor authentication on their
Google accounts?
Do they require all those people to only access
their Google accounts on fully patched computers?
Do they require all those people to run up-to date
anti-virus and anti-malware programs?

If I was a bad person wanting to get hold of this information I would not attack Google I would attack the machines/accounts in the school which have access to the information. This would remain the case no matter how the data was gathered as long as it was stored electronically.


How to make sure my data is secure even if someone gains physical access? I've been reading up on how to secure my data if someone has gained physical access to the machine, e.g. stolen it. And that seems like a very hard thing to do, as indicated by a number of posts.

It is certainly possible to make it harder to gain access to the data. But it has to weighed against the ease of using it. If it becomes to cumbersome, the likelihood of taking shortcuts greatly increases.

I am not storing NSA secrets or company financials. Just family photos, documents, and a few personal keys and certificates. But I'm disliking the thought of someone possibly gaining access to it.

What are some manageable ways for me to protect my data if my home computer and/or backup NAS gets stolen?

Update: Full disk encryption seems to be the answer. I have all my personal files on the D drive, is it enough to just encrypt that?

Disk Encryption seems like the easiest way to take care of your data in this situation, and password protecting your things is a great deterrent. Set a strong password on your laptop, and if you're using a USB thumbdrive with password capabilities I'd set that up too. The goal is really to mitigate the theft of the data, so when you think about this sort of protection don't think of it as how to keep the physical items safe, but how can I keep the data safe if someone got their hands on it, and in that respect the more hoops an attacker needs to jump through in order to view the data, the more deterred they will be. Consider a home security system as a point of reference; the system doesn't prevent someone from breaking in, but the threat of the alarms makes a thief reconsider.

One other method you may want to consider is backing up any personal data like this on to something like a portable HDD or a home server. If you take your laptop out and it gets stolen, at the very least you know the thief hasn't gotten away with much, and you have a backup of everything you want to keep to boot. Something to think about at least. Hope this helps!


Unable to "trust" self-signed certificate I am currently running a setup that interfaces with many appliances running HTTP servers (running on Windows Embedded). The connections I use are HTTPS connections. My problem is, every time I open the web portal of those appliances (simple HTTPS servers that display some info), I get a "There is a problem with this website's security certificate" warning.

I have tried adding that certificate to the Trusted Root CA certificates, but I still get that prompt. I tried doing it from IE directly, and from certmgr.msc (after exporting the certificate file) with the same unsuccessful result. No matter what I tried, I still get that prompt.

Is there anything I might have overlooked ?

EDIT: Requested screenshots

The error message

  The security certificate presented by this website was issued for a different website's address

indicates that the URL that is embedded in the cert is different from the URL that you are typing into the address bar of your browser. Once you put a cert on a server, browsers will only let you access it through its full public domain name (as a defense against man-in-the-middle attacks).

Are you trying to access your server by its IP address or by a local hostname?


OIDC: should the provider have the same address as the issuer? I'm using Coreos OIDC library for Go. When setting up an OIDC config (coming from PROVIDER_URL/.well-known/openid-configuration), I'm getting this error:

Could not initialize OIDC provider:oidc: issuer did not match the issuer returned by provider, expected "PROVIDER_URL" got "ISSUER_URL"

... because of a library check.

Should the provider have the same address as the issuer?
Is that check part of the RFC?

Yes, the requirement is stated in the provider configuration section of the specs (emphasis mine):

  OpenID Providers supporting Discovery MUST make a JSON document available at the path formed by concatenating the string /.well-known/openid-configuration to the Issuer. The syntax and semantics of .well-known are defined in RFC 5785 [RFC5785] and apply to the Issuer value when it contains no path component. openid-configuration MUST point to a JSON document compliant with this specification and MUST be returned using the application/json content type.

It also goes on to mentions that:

  The issuer value returned MUST be identical to the Issuer URL that was directly used to retrieve the configuration information. This MUST also be identical to the iss Claim value in ID Tokens issued from this Issuer.

In practice I'm aware that a few of the mainstream providers such as Microsoft doesn't stictly follow this pattern but you'll have to take it up with them, or consider the workarounds given by the OIDC library.


Are all unsalted password hashes inherently insecure? Maybe I'm missing something obvious...

Are all passwords stored in common, unsalted hash algorithms able to be attacked via rainbow tables?

Not all passwords. When the password is sufficiently long and random to not appear in a reasonably-sized rainbow table, salting is indeed unnecessary.

The purpose of a salt is to increase the length of the password to a level where rainbow tables are unfeasible. When the password already has enough entropy, the salt becomes redundant.

When your salts are 32bit, demanding about 5 more characters of mixed case, letters and special characters without a relation to a dictionary word would be equivalent.

However, passwords used by the average user do not have enough entropy to be rainbow-table-proof. So unless you have the ability and authority to enforce a strict password policy and users who understand that they must not try to find loopholes (hey, Password123! is 12 characters mixed case with letters and special chars!), you should still use salting.


if PCI DSS requires encrypted storage of credit cards, what are requirements for storing the decryption key? https://www.pcisecuritystandards.org/documents/PCIDSS_QRGv3_2.pdf
requires that you encrypt stored credit card information -- for example, if you're an online merchant like Amazon that allows repeat customers to order without re-entering their credit card number.  But it doesn't seem to have any requirements about how you store the decryption key, only that you document what you're doing: "Document and implement procedures to protect any keys used for encryption of cardholder data from disclosure and misuse" and "Fully document and implement key management processes and procedures for cryptographic keys used for encryption of cardholder data".  Does that mean that if you store the decryption key right there on the same disk as the encrypted credit cards (with some restrictive file permissions, at least), that's OK, as long as you document that's what you're doing?

If your answer is "No, you need to do XYZ", can you clarify whether (a) you are referring to some requirement laid out in the PCI DSS that I missed; or (b) you're talking about a requirement that's not laid out in the PCI DSS, but it's an unwritten rule that the PCI Security Standards Council holds people to anyway.

(If I were trying to do it securely, I'd have the decryption logic carried out on machine A, the decryption key stored on machine B where it can only be retrieved by machine A, and the encrypted card numbers stored on machine C where they can also only be retrieved by machine A.  Since the key and the card number have to be stored somewhere, I don't think you can do better than this, unless you start splitting the encrypted card number across multiple machines so that the attacker has to read each one in order to piece it back together.  But I'm not asking what is most secure, I'm just asking what the letter of PCI DSS requires.)

You need to look at the full specifications (available https://www.pcisecuritystandards.org/document_library?category=pcidss&document=pci_dss), rather than the quick reference guide to get more details - this covers it in detail in section 3.5.3:

  Store secret and private keys used to encrypt/decrypt cardholder data
  in one (or more) of the following forms at all times:

  Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key
  Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of-interaction device)
  As at least two full-length key components or key shares, in
  accordance with an industry-accepted method

Other sections around this cover other points, such as how to check that these requirements are being met, and the specific types of documentation needed.


Can I use VeraCrypt with an SSD? I recently got Windows 10, and I am not overly thrilled at Microsoft having a copy of my password on their servers. I will also be forced to make a hotmail account, instead of just using a local account. I am forced to use Windows because of my job, so iOS and Linux are out of the question.
Is there a way of using Bitlocker full disk encryption with just a local account, and without sending Microsoft a copy of my key?
If I have to use VeraCrypt (without the plausible deniability) would I have problems because I am using a branded Samsung laptop with an SSD which likely uses TRIM.
I miss the old days of local Windows accounts, and mechanical hard drives, but I am forced to stick with my current setup.

VeraCrypt (or any other full volume encryption) can be (and has been for many years) used with SSDs. An attacker with the tools to access the drive metadata will be able to determine some things about what blocks are used or not, but won't be able to actually decrypt anything or otherwise compromise your data.

As a side note: Win10 still supports both local and domain accounts (in addition to Microsoft accounts), and neither one sends your recovery key to MS. So, this entire question is based on a false premise. I also suspect it's possible to use BitLocker with a MS account but not send them the recovery key - worst case, you can remove the recovery key from the drive - but it sounds like you don't want to do that anyhow.


Scan Novell NetWare backend with Windows servers and clients Could anyone provide some insight on performing an internal vulnerability assessment regarding Novell NetWare as the backend with client workstations and servers running various versions of Windows?

Essentially, I'm looking for tools or techniques on how to run a thorough scan by joining my machine to the Novell "tree" and then launching a scan against the Windows workstations and servers. Additionally, it would be beneficial if a tool exists that scans for vulnerabilities on both systems.

Other questions surrounding this are:

If there is a separate Windows domain, would I have to join that domain in order to run a scan?
If the Windows machines are part of a WORKGROUP, would I just need to join the Novell "tree" and enter the Windows admin credentials inside of a scanner tool to scan the Windows machines?
Could I join the WORKGROUP and run the scan with the Novell NetWare admin credentials used inside of the scanner tool?

To sum up, a person plugs their laptop into an environment running Novell NetWare and wants to scan the Windows clients connected to the Novell server. Please ask for more detail if necessary.

It depends if you want to do an unauthenticated (black box) style scan or internal audit type scan.  Some scanning tools can check to see if you are missing any patches, in that case you will need to have local credentials for the windows systems.  You will need to use an account that is present on each Windows system with proper rights.

So yes, you could use the workgroup credential to scan the workstations and you don't necessarily need to join the Netware tree.


Choosing Key and IV in AES-256 I am working on a real-life project for a firm. I have to encrypt data using AES 256 as per specification. I want to know how are the key and IV are really chosen in real world projects. /dev/urandom is good enough for both? Any other advice regarding these?

All that is necessary is that the values are random and unique. It is perfectly acceptable to pull them from your operating system's cryptographic random API or from a crypto library like OpenSSL that contains its own internal cryptographically secure random number generator (CSPRNG).


Attack vectors with encrypted SAML assertion response I'm testing a web application which uses SAML SSO. SAML Response has signature and  it is verified correctly if data is tampered. But I noticed that when signature is removed completely authentication to SP succeeds. In general, it's clear what is the issue/vulnerability here but assertion data is encrypted so I'm not able to modify any of the data.

I can for example login with admin level user, store response and let it expire. Then I login with lower level user, stop response and change IssueInstant etc. values to get pass of expiration and copy admin level users encrypted values to response but then I get response that assertion is expired. So it seems that assertion includes own expiration time and that is inside encrypted data.

In above scenario attacker would of course gain access to admin’s old SAML response somehow(access to admin's browser cache or with access to some logs) but that isn’t really relevant.

So question is that can there still be some real attack scenarios without ability to break used encryption of the assertion or does encryption mitigate invalid signature check completely?

Either the SAML response or SAML assertion should be signed and the signature verified.

An XML signature permits the identity of the sender to be confirmed and any changes to the signed XML to be detected. This ensures the integrity of the XML.

Otherwise, the SP has no way of knowing who sent the SAML response or assertion and whether it's been altered after signing.

In your scenario it's possible that the encrypted assertion is signed and the SP is verifying the assertion's signature. However, it's unusual for both the SAML response and assertion to be signed so I would question whether the assertion is actually signed.

Encrypting the SAML assertion ensures privacy but anyone with access to the SP's public key can create and encrypt an assertion.


Website invalid security certificate On a home LAN I encountered this error both in Linux Firefox (an ubuntu vmware VM on Win7) and from my Android phone browser from a shopping website during the checkout process a few days ago. Could this indicate some sort of MITM compromise (eg in the LAN router)?  DNS compromise? Could this also be from one of the content delivery network (CDN) machines serving the paypal content being incorrectly configured or being compromised?

  This Connection is Untrusted

  You have asked Firefox to connect securely to www.paypal.com, but we
  can't confirm that your connection is secure.
  Normally, when you try to connect securely, sites will present trusted
  identification to prove that you are going to the right place.
  However, this site's identity can't be verified.

  What Should I Do?
  If you usually connect to this site without problems, this error could
  mean that someone is trying to impersonate the site, and you shouldn't
  continue.
  This site uses HTTP Strict Transport Security (HSTS) to specify that
  Firefox only connect to it securely. As a result, it is not possible
  to add an exception for this certificate.

  www.paypal.com uses an invalid security certificate.

  The certificate is only valid for the following names:
  google.com, *.2mdn.net, *.android.com, *.appengine.google.com (many
  more names...)

Running nslookup on the linux machine

@1pm

  nslookup www.paypal.com
  Server:                 127.0.1.1
  Address:                127.0.1.1#53

  Non-authoritative answer:
  Name:             www.paypal.com
  Address: 216.58.217.194

Then @1:45

  nslookup www.paypal.com
  Server:                 127.0.1.1
  Address:                127.0.1.1#53

  Non-authoritative answer:
  www.paypal.com    canonical name = www.paypal.com.akadns.net.
  www.paypal.com.akadns.net   canonical name =
  ppdirect.paypal.com.akadns.net.
  ppdirect.paypal.com.akadns.net        canonical name =
  wlb.paypal.com.akadns.net.
  wlb.paypal.com.akadns.net             canonical name =
  www.paypal.com.edgekey.net.
  www.paypal.com.edgekey.net            canonical name =
  e3694.a.akamaiedge.net.
  Name:                                 e3694.a.akamaiedge.net
  Address: 184.86.122.156

What would be a remediation plan? Replace the home LAN router? Would all the devices on the home LAN also be suspect?

This is a really bad one. Someone delivered this fake certificate to you in the intend of being able to decrypting your HTTPS connection. As it's paypal.com it's very likely that the attacker wants to capture your credentials. This can result in looting your bank account so you better don't trust this connection.

Its hard to say in which step of the connection the MITM attack was performed or if it anyway was a MITM. It could also be maleware that installed a proxy on your host that replaces the real certificates with faked ones.

MITM Attacks can be performed in the LAN easily but can also be based on the manipulation of your or your ISPs router.


Understanding OpenWRT LuCI Firewall Routing with VPN I'm still fairly new to networking, and I'm having a little trouble grasping some concepts of the proper firewall rules I need to implement for my desired setup. I'm setting up a router with OpenWRT and OpenVPN to route incoming traffic through my VPN provider (proxy.sh). I've largely got things setup adapting from these two guides:

blog.ipredator.se/howto/openwrt/configuring-openvpn-on-openwrt.html
tokyobreeze.wordpress.com/2015/01/15/install-openvpn-in-a-router-with-4mb-flash/

One thing I'm having trouble understanding is OpenWRT's LuCI firewall rules. The basic idea is all traffic coming in from the LAN port is forwarded to the VPN interface and packets are masqueraded behind the VPN interface. If the VPN disconnects, then traffic is dropped and no ip is leaked. Where these guides differ is in one, the WAN (which connects to the web) port is set to its normal settings with input rejected, and masquerading on (see below image)

While the other guide instead turns off masquerading on the WAN port, and allows input (see below image).

Both configurations work for me, (and pass all the tests on ipleak.net) but I'd like to better understand what's going on and make sure I'm secure. So can someone please explain/help me understand...

If and why one approach is better or more secure than the other?
These rules/how the packet routing actually works? I don't think I quite understand what is going on. For example, I don't understand why if masquerading is turned off on the WAN interface, input needs to be allowed on the WAN interface (I checked this config and ineed it doesn't work unless WAN input is allowed). The explanation the author gives is too brief and doesn't make sense to me. My understanding (which is probably wrong) of input not being allowed is that the interface only accepts packets returning from an outgoing request and not packets from a new connection (again new to networking here). So if a packet is sent out over the VPN interface (with WAN masquerading turned off), why is its return packet rejected by the WAN interface if WAN input is disallowed? Wouldn't it be a response just like any other?

To answer question 1, I don't think either setting is as secure as you ought to be.  Option 1 leaves masq turned on for the WAN when it doesn't need to be.  Option 2 sets up a default accept rule for the WAN when it doesn't need to be.

To answer question 2 and fill in the blanks on question 1: The input/output rule settings in OpenWRT are the default behavior for traffic.  Specific rules can then be added to deviate, for example if you set the WAN to input reject (which is the default), you then need to go in and specifically allow things to happen (like masquerading to do NAT which is there by default, or an accept rule to allow incoming SSH which is not there by default and hence no SSH can come from the WAN to the router). When you turned of Masquerade and left the WAN config at reject, there was no way for anything to get in that didn't fit into an allow rule (even OpenVPN traffic).  If you then went to the firewall traffic rules and specifically allowed the OpenVPN traffic through (1194 UDP by default), it would work in reject mode.  This is a better choice since leaving the WAN in accept means any services on your router (like ssh or SMB) are left to fend for themselves against incoming (possibly malicious) traffic.  It's best practice to deny everything and then poke just what you need through.


Is it possible to create a new image standard which supports privacy? After watching a TED video on sexting, I heard about that 17 years old girl who committed suicide because her boyfriend shared her private pictures in their school.
I wondered if it is possible to create a new standard image format which takes into account the privacy issues. Basically thinking, it may add another piece of EXIF data which defines the forward ability or number of times the image can be forwarded to anyone else. Or a number of times that image can be seen, like self-destructing image after one view. For the digital rights, a unique ID can be coded into the image which may be able to trace it to some degree. I don't know how to prevent screenshots.

This kind of privacy related data should be non-editable for the end user. I know it's almost impossible but at least operating system built in prevention may prevent many incidents.

If you can read it, you can copy it. This is why all attempts at copy-protection are doomed from the start.

You can make it harder for the end user to forward it, like in the scheme you suggest. But somebody will build a custom version of the OS and modify it to ignore the EXIF note that forbids forwarding.

If nothing else, a user can always take a picture of the phone while it is displaying the picture.

So - no, a standard like that is not feasible. From a technology perspective, the best you can do is make it harder, but people will always find and use ways to evade it.


Is it possible to tell if hard drive is encrypted? Is it possible to tell if a hard drive is encrypted, regardless of what software was used, i.e., Truecrypt / VeraCrypt / Bitlocker for AES-256?

Just the other day, I thought it could be possible to tell if I scan the drive with "Sector View" to read the data. If the data is filled with randomness then that means that it is encrypted. Is it that easy to tell?

We have two types of encryption here, "file based encryption" and "full disk encryption". There are documented forensics methods and software (e.g. EnCase) that help us detect the schemes and programs used to encrypt the disk.

I'm going to take a list of popular tools and standards and see if they leave any traces with which we can determine that they've been used:

Bitlocker
Bitlocker is a full disk encryption standard available on windows operating system from Windows 7 onwards; this tool uses AES256 to encrypt the disk. A disk encrypted by bitlocker is different than a normal NTFS disk. The signature of "-FVE-FS-" can be found at the beginning of bitlocker encrypted volumes.
These volumes can also be identified by a GUID:

for BitLocker: 4967d63b-2e29-4ad8-8399-f6a339e3d00
for BitLocker ToGo: 4967d63b-2e29-4ad8-8399-f6a339e3d01

DiskCryptor/TrueCrypt/VeraCrypt
DiskCryptor is based on TrueCrypt. For both DiskCryptor and TrueCrypt we can detect their presence with the following criteria:

size of file or collection of clusters object is a multiple of 512,
minimum size of object is 19KB, although by default is minimum 5MB,
contains no specific file signature throughout the entire object, and
has a high Shannon entropy or passes Chi-squared distribution test.
Note that since there's no specific signature or header left behind we can't tell for sure if TrueCrypt (or its siblings) were used, by combination of several methods we can try to make better guess about its presence.

FileVault
Filevault is Bitlocker's equivalent on Mac and offers full disk encryption. The signature of "encrdsa" or hex value of "65 6E 63 72 63 64 73 61" can be found at the beginning of FileVault encrypted volumes.
cryptsetup with LUKS
Linux Unified Key Setup is a disk encryption specification and can be used in cryptsetup on Linux which is a common tool for storage media volumes encryption. It is optional and users can choose not to use this format but if used we can detect its presence with "LUKS\xba\xbe" signature at the beginning of the volumes.
Check Point Full Disk Encryption
At sector offset 90 of the VBR, the product identifier "Protect" can be found. Hex value "50 72 6F 74 65 63 74"
GuardianEdge Encryption Plus/Anywhere/Hard Disk Encryption and Symantec Endpoint Encryption
At sector offset 6 MBR, the product identifier "PCGM" can be found. Hex value "50 43 47 4D"
McAfee Safeboot/Endpoint Encryption
At sector offset 3 MBR, the product identifier "Safeboot" can be found. Hex value "53 61 66 65 42 6F 6F 74"
Sophos Safeguard Enterprise and Safeguard Easy
For Safeguard Enterprise, at sector offset 119 of the MBR, the product identifier "SGM400" can be found. Hex value "53 47 4D 34 30 30 3A"
Symantec PGP Whole disk Encryption
At sector offset 3 MBR, the product identifier "ëH|PGPGUARD" can be found. Hex value "EB 48 90 50 47 50 47 55 41 52 44"

Measuring File Randomness To Detect Encryption

Methods discussed earlier may not be feasible for every disk/file encryption scheme since not all of them have specific properties that we can exploit to detect them. One other method is to measure the randomness of files and the closer they are to random, the more certain we are that encryption is used.
To do this we can use a Python script named file_entropy.py. The closer the entropy value is to 8.0, the higher the entropy.
We can extend this further and draw plots to visualize the distribution of bytes. (calculate-file-entropy)

One other pointer to detect encryption is that no known file signature will be spotted in the volume. (No jpg, no office documents, no known file types) And since compression methods (e.g. gzip, rar and zip) have known signatures we can differentiate them from encryption for the most part.

Sum up

Use known signatures to detect encryption (if possible)
Use special characteristics (minimum file size, high entropy, absence of any special file signature, etc.) to detect encryption
Rule out compressed files using their signature

So going back to the main question, "Is it that easy to tell?", this falls under forensics methods, we may be dealing with steganography techniques. In a normal case where user isn't trying to fool us, it is somehow easy to tell encryption is in place but in real world scenarios where user's may try to hide things and deceive us they may just pipe /dev/urandom to a file! It's not gonna be easy.


How to prove a user is actually the perpetrator of certain actions? TL;DR : What is the best and most "by the book" way to accheive non repudiation of origin.

I have a system in which users can perform actions (register/unregister/...)

Those actions are signed by my users with private keys they own.
They also save their public keys in their profile.

What prevents a user to tell me that I made actions in h{is,er} name, pretending that they don't know that "public/private key thingy" (in case they are malicious).

Thing is I will never be able to prove that they DID own the private key. They could throw it away (or just never disclose it).

I thought i could ask them a question that

only them know
is hard to guess
easy to verify

But I can't seem to find out what question that could be.

I thought I could ask for a photo of their Id/Driver Licence taken in front of an app-generated image on their screen. But is it "proof enough" ?

Not sure I totally see the problem. Are you concerned that a user could claim you used their private key because you have access to all users keys?

Private keys should ideally be stored one for each user and not in the system itself. I don't know the ins and outs of your system, but could you not get each operation to require the user to attach their private key to complete the operation (this could even by handled client side in some sitations so you can maintain a true 'Trust No One' approach)

If you are concerned users will claim they never owned the private key can't you make a step in the operations to require proof of private key. Such as requiring the users to decrypt something your system encrypts using the public keys?


Client Hello message suggests cipher suite which is not in the list specified by setEnabledCipherSuites() method In my code, I use JSSE6 API to specify a list of enabled cipher suites. I aimed to only allow 168 bits or higher encryption cipher suites, below is a part of my code:

/** List of 168 bits encryption or higher cipher suites */
private static final String[] ENABLED_CIPHER_SUITES_168 = {
    "TLS_RSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDH_RSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
    "TLS_DHE_RSA_WITH_AES_256_CBC_SHA",
    "TLS_DHE_DSS_WITH_AES_256_CBC_SHA",
    "SSL_RSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA",
    "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
    "SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA",
    "TLS_EMPTY_RENEGOTIATION_INFO_SCSV",
    "TLS_KRB5_WITH_3DES_EDE_CBC_SHA",
    "TLS_KRB5_WITH_3DES_EDE_CBC_MD5",
    "SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA",
    "NETSCAPE_RSA_FIPS_WITH_3DES_EDE_CBC_SHA",
    "SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA",
    };
// return a list of cipher suites which match both array
String[] list = matchStringArrays(ENABLED_CIPHER_SUITES_168, ((SSLSocket)socket).getSupportedCipherSuites());
// Set a list of enabled cipher suites
((SSLSocket)socket).setEnabledCipherSuites(list);

But when I test my app with some SSL scanner tool, they say that my server allows 96-bits encryption cipher suites?

Then I use Wireshark to capture packets of then SSL handshake process, I found that in Client Hello message, there's a cipher suite that is not in my list of enabled cipher suites. The cipher suite is

ssl2_des_192_ede3_cbc_with_md5

How can this cipher suite appear in the the client hello message?

The SunJSSE provider does not support SSLv2. It does support sending the first ClientHello message of the SSL/TLS handshake in SSLv2 format, though.

A client sending the ClientHello message in SSLv2 format is useful if the client is ready to actually use SSLv2. However, since SunJSSE does not support SSLv2, it sends the ClientHello in SSLv2 format for a weaker reason: this is to support old, buggy, legacy servers that know SSLv3 but expect the ClientHello in SSLv2 format, and simply hang up when faced with a "normal", SSLv3-format ClientHello (such servers exist because when SSLv3 was designed and deployed, SSL clients soon took to the habit of sending the ClientHello in SSLv2 format, so receiving an SSLv3 ClientHello was not really tested).

This sheds some light on what SunJSSE will do: it will send a SSLv2 ClientHello not to actually do SSLv2, only to be able to connect to some old servers that expect that message format and then proceed to use SSLv3. The SSLv2 ClientHello will also contain, in the list of cipher suites, the codes for the SSLv2 cipher suites -- that the client does not actually support, since it does not know SSLv2. These cipher suites are thus harmless: the client has no intention of using them and indeed does not know how to use them; it includes them just to make the ClientHello message more "SSLv2-like". The client strongly expects the server to respond with a SSLv3 ServerHello, the SSLv2 cipher suite being ignored.

Disabling support for that "SSLv2 ClientHello format" is still a good idea, for the following reasons:

Though the JDK from Sun/Oracle uses SunJSSE for SSL, another Java implementation may include full SSLv2 support (IBM's implementation is reputed to do that), and you don't want to inadvertently use the complete SSLv2, since it is weak in several ways.
There is a strong push to disable SSLv2 completely. Servers may cease to support the SSLv2 ClientHello message format. They might be some old buggy servers that require a SSLv2 ClientHello; but there also are some new, non-buggy server that don't support SSLv2 ClientHello; and the latter will be more and more prevalent as time passes.
Even when they do support it, that format cannot contain SSL extensions, e.g. Server Name Indication, so using the SSLv2 ClientHello format may prove limitative.

Nowadays there is a lot of talk about disabling SSLv3 too, and forcing TLS 1.0 or higher, so clinging to SSLv2 will make you look unfashionably archaic.


CORS accepting arbitrary origin with GET but not with OPTIONS I'm testing an API, which allows an arbitrary origin on POST/GET requests, by responding with the CORS header Access-Control-Allow-Origin: *.

However, with OPTIONS requests and an arbitrary origin, the web service does not respond with Access-Control-Allow-Origin: *, it does not use the response header at all.

This means that any CORS preflight requests with an arbitrary Origin, would fail.

I don't see the point in having the CORS response header for GET/POST requests, but not the OPTIONS request. However, I also can't provide an example for a vulnerability or how this may be exploited.

Q: Is it safe to say that does not pose a vulnerability, but is just bad practice?

Q: Is it safe to say that does not pose a vulnerability, but is just bad practice?

Since it's an API and assuming it requires Authorization header for all requests, it's safe to say that it doesn't pose a vulnerability. The behavior, however, limits communication to same-domain.

It's worth noting that not all requests are preflighted. Please refer to https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests for more details.

An API expects, if properly configured, a proper Content-type header and an authorization header which in most cases is Authorization. If a request sets a "forbidden header name" or an unsafe Content-type, it's always preflighted. And as such, no other domain would be able to send an authenticated request at all.


Returning POST JSON data securely? I have a webpage (HTTPS encrypted and authorized only via domain credentials) that displays grid information. This grid information is received via a POST request to my server which will send  back all of the pertinent information in JSON format.

My javascript code is obfuscated, but all the return data is easily viewable via the network tab of Chrome's developments tools, by finding the POST request response (which is quite large and easily spotted).

Now, although everything is secure, so this information can only be retrieved by valid users, I do not want them to be able to be able to view the entire data block that is returned.

Are there better ways of returning data that cannot easily be extracted by Chrome's network development tools? Or am I basically looking at implementing another level of encryption on the JSON data itself, and only decrypting the data locally when I choose to display parts of it?

From a security perspective the answer is to never send anything you don't want the user to know to any system the user controls.

From a UX perspective, having a bunch of extra data that's only visible if they open developer tools shouldn't be a problem. Anything they see in developer tools isn't "user experience", it's developer experience. Having stuff encrypted or encoded just makes the "developer experience" worse.

From a performance perspective, having multiple, or many, or uncachable, GET requests usually isn't a huge problem. The details depend a lot of your tech stack and your end-users' situations, but typically you can mitigate related performance problems by

Looking at your caching situation. Don't go overboard, but, counting the user's browser-cache, caching at two or three levels of the tech stack may be appropriate. Particularly, your server could cache a broad DB query, and then perform filtering before sending the data to the client.
Tune your server. This is a massive rabbit-hole; the specific thing I'm suggesting is that you make sure HTTPS connections are being kept open for a little while. 30 seconds or so is often good. That will speed up HTTPS requests that happen while the connection is still alive.
Batch requests. Either let the client request large lists of specific resources in a single request, or move (even duplicate) the logic that would determine what followup resources are going to be needed from the client to the server. You could also look into using HTTP/2 Server Push.
As a last resort, just buy a more powerful system. It won't make an unworkable solution workable, and it'll feel like a cop-out. But it can make a sluggish system feel performant, and it will handle larger traffic spikes without hanging.


Can the government monitor my online activity when I use VPN? Many social networking and popular websites are blocked where I live. There are certain workarounds to access these services however, including VPN services provided by certain local providers with servers abroad located in several countries. However, these workarounds are getting increasingly unreliable so one has to switch between various applications such as Open VPN, OpenConnect, Cisco AnyConnect, etc. though they only seem to work for a certain period. I recently faced an IE notice when opening YouTube through one of these VPN services saying the connection is insecure, as shown in the following screen shot:

Can the government track and intercept my online activity even when using VPN?

I also reside at a location, where the government blocks a number of websites related to security, and although the majority of their effort is around blocking pornographic content, I am sometimes bothered by the categorization of the content filter, or their choice of blocked sites. But it's not the blocking that bothers most, it's the fact that their Internet use is generally monitored and recorded in this country.

If your question is "can governments decrypt my VPN traffic", the answer is "depends". There is a concentrated effort by the Five Eyes intelligence agencies, and the effort (and partially its results) has been brought to us thanks to Ed Snowden (check out the Turmoil/APEX projects high-level info here (Der Spiegel magazine dumps), mainly focused on IPSEC). OpenVPN's TLS use also depends heavily on the implementation at hand, although 2048-bit RSA still is considered "out of reach" for the big guys.

Having said that, the other things that a government can do:

The government agency that monitors Internet communications knows you are using a VPN. They may interpret this as "this person has something to hide". So you've probably ticked the first box in the "surveillance target" selection scheme.
Using various techniques and patterns they would be able to ascertain and identify you from other VPN users across a variety of locations - a coffee shop, a friend's house, etc.
Using these patterns they will try and track your non-VPN activity to build a profile and to start using other methods to monitor your posts, etc.
They may try to run VPN disruptive techniques to bump you off the VPN, so your browser and/or other programs leak unencrypted packets in the immediate aftermath of the VPN going down. That will give them an idea what are you up to, e.g. hosts you're sending packets to, or even limited content.
There have been attacks on VPN traffic that may help them discover certain patterns (e.g. when do you come back home from work).

In general many commercial VPN providers do not provide you with measures that will ensure maximum protection - they're not going to give you the strongest encryption, because that's more overhead for their servers. Also, because of their commercial activities, they do attract a lot of undesired attention.

My general recommendation is to run your own server - rent a cloud server for something like $19 a month within a country that generally won't be as keen on eavesdropping on your funny cat pics surfing habits over social media. In addition to that, run a legitimate mail server on it, and a WordPress site, and if anyone asks - you're just securing your connectivity to your mail/business server. You'll be using the VPN for legitimate business reason. Not that it will be a deterrent, but may win you the benefit of the doubt.


How does the OpenSSL Alternative chains certificate forgery (CVE-2015-1793) attack work? The security advisory for the issue can be found here: https://www.openssl.org/news/secadv_20150709.txt

  OpenSSL Security Advisory [9 Jul 2015]

  Alternative chains certificate forgery (CVE-2015-1793)

  Severity: High

  During certificate verification, OpenSSL (starting from version 1.0.1n
  and
  1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the
  implementation of this logic can mean that an attacker could cause
  certain checks on untrusted certificates to be bypassed, such as the
  CA flag, enabling them to use a valid leaf certificate to act as a CA
  and "issue" an invalid certificate.

  This issue will impact any application that verifies certificates
  including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client
  authentication.

  This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.

  OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d OpenSSL
  1.0.1n/1.0.1o users should upgrade to 1.0.1p

  This issue was reported to OpenSSL on 24th June 2015 by Adam
  Langley/David Benjamin (Google/BoringSSL). The fix was developed by
  the BoringSSL project.

  Note

  As per our previous announcements and our Release Strategy
  (https://www.openssl.org/about/releasestrat.html), support for OpenSSL
  versions
  1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these
  releases are advised to upgrade.

  References

  URL for this Security Advisory:
  https://www.openssl.org/news/secadv_20150709.txt

  Note: the online version of the advisory may be updated with
  additional details over time.

  For details of OpenSSL severity classifications please see:
  https://www.openssl.org/about/secpolicy.html

From the description, one may infer that the attack works the following way (warning: I wrote "infer" and I mean it -- I have not tried it):

The attacker is in position to intercept all network traffic from the victim (e.g. the attacker operates the WiFi access point to which the victim unwisely connected).
The attacker owns (legitimately !) some domain, let's call it "evilattacker.com", and has bought a completely valid certificate with that name in it; namely, the attacker owns a certificate A, that contains the name www.evilattacker.com, and is signed by some trusted root V. The attacker pushes a copy of that certificate (the public key) on a publicly accessible Web site, say his own site; the corresponding URL may be (for instance) http://www.evilattacker.com/cert.crt (it could also be on any kind of public hosting, it does not matter).
The victim wants to connect to its bank site. His browser tries to open a SSL session with www.bank.com.
The attacker intercepts that connection and pretends to be the bank. To that effect, the attacker sends a certificate chain C,X (in that order) where:

C is a synthetic certificate that contains the name www.bank.com, and is signed with the attacker's own private key, and contains an Authority Information Access extension with a URL equal to http://www.evilattacker.com/cert.crt (that is, pointing to where the attacker has published his own certificate C).
X is random junk.

The client (victim's browser) will fail to validate the C,X chain, because X is random junk. If the browser uses an old OpenSSL, then things stop there and a connection error is reported. However, if the browser uses a new, affected version of OpenSSL, then it will try to rebuild an alternate chain, following the URL found in C. In particular, the browser will download A (the attacker's certificate) and then V (the external, trusted certificate authority), and will end up with the C,A,V chain.
If there was no bug, then the client would reject that new C,A,V chain because even though all cryptographic signatures match, the middle certificate A lacks the Basic Constraints extension with the cA flag set to TRUE: the attacker's certificate is not a CA certificate, so it cannot appear in the middle of a valid chain. However, due to the bug, in that specific situation, affected versions of OpenSSL fail to check the cA flag in the Basic Constraints extension, and accept that C,A,V chain as valid. The browser is persuaded that it talks to the genuine bank server, and proceeds without any warning. The attacker can now run a Man-in-the-Middle attack and plunder the victim's bank account.

Ironically, failure to check the Basic Constraints extension for middle certificates was also a bug in Windows / Internet Explorer circa 2003, and Microsoft was duly and heavily mocked for that; the OpenSSL developers thus just lost all rights to such mocking.

The bug impacts every application that uses an affected version of OpenSSL (not a lot of them, since the buggy code was added only recently), and is in position to process a certificate chain sent by a potentially hostile peer. This means SSL clients (when validating a server's certificate); this also means SSL servers themselves, when (and only when) these servers request certificates from clients (certificate-based client authentication is pretty rare in everyday's Web).


Do HP ProCurve 1810G Config files have password hashes or other sensitive info? I'm backing up some switches and I'm wondering if this config file should be kept secure. It is in binary so I do not know what it contains.

What do the config files contain?

The password is very likely somewhere in that binary blob, so yes, you should keep the backup file safe.

A while back I stumbled across http://www.happyhacking.org/Happy_Hacking/Blog/Entries/2010/3/20_HP_ProCurve_1810G_Take_2.html which has some details on the binary.

btw: the 1810G stores the base64-encoded password in your authentication cookie, so you might want to take care of that as well...


Few questions about network hacking I have a few questions about network hacking:

Can I infect the entire network (all computers, servers inside) if I broke into and infect the router? If so, how?
Imagine a corporation that has a website on their private servers in your private network. Can I track down the router using information from the website?
I think I can if any traffic from/to/in network flows through the router. So if I can connect to the server site, I can also connect to the router. If so, how?
At security.stackexchange.com (Router being infected by malware) I read that if you have full access to the router you can change the DNS settings so that all network traffic
flows through your computer (man-in-the-middle between my computer and attacked router) and you can inject malicious code into traffic to any computer in that network. Is such an attack feasible?

Can I infect the entire network (all computers, servers inside) if I broke into and infect the router? If so, how?

Not really. It isn't the fact that you broke into the router, that "only" gives you a foothold. You've still then got to break into the computers in that network. However, you are a major step closer and that's why enterprise networks are segmented. You are also confusing a home network where the router and firewall are the same device with an enterprise network where, typically they are not. In those cases, the firewall and possibly several other protection devices are inside the router.
Can I track down the router using information from the website?

Maybe. But only if the server is in the same network as the router. This is likely to be the case in smaller networks but may not be in larger ones that may have several DMZ networks. In those cases, you may only be able to find the nearest router or firewall.

So if I can connect to the server site, I can also connect to the router. If so, how?

Nope, same problem as before. While you know where the device is logically speaking, you still don't know the credentials to get into it to do anything "useful".
change the DNS settings so that all network traffic flows through your computer ... inject malicious code into traffic to any computer in that network. Is such an attack feasible?

Partially. If the network were using something like DNSsec then probably not at all. Otherwise, you would still need to MITM any HTTPS/TLS certificates, it isn't enough to have a MITM for the raw traffic if that traffic is encrypted.

But in an internal enterprise network, it is less common for the traffic to be encrypted between machines. It causes overheads in running and also in operational support so it is often ignored. In that case, your MITM device would have to also be inside the network of course and not outside. Another good reason for large networks to be segmented since it limits the number of machines a rogue element can get to.


Sniffing the whole traffic within a network range How is it possible to sniff the whole traffic within a network range even if it's beyond your subnet scope?

For instance, consider your machine having the IP address of 172.16.96.25, but you need to sniff the whole traffic between 172.16.96.1 - 172.16.111.254.

Machine Info

Machine OS : Linux or MacOS
Tools : No Difference, I'm open to use anything but preferably WireShark

Assuming you're on a wired Ethernet network, you'd need to ARP Spoof-attack the layer 2/3 device in your network so your ethernet interface (in which Wireshark will be listening) could get all the traffic from the subnet. The ARP spoof will cause the network devices to believe you're computer's ethernet interface is the switch/router's path to send the frames. If you have direct access to the switch/router then it wouldn't be a problem, but most if the time this is not the case and that's why the ARP spoof is required.

Here's some explanation for it from Wireshark:

https://wiki.wireshark.org/CaptureSetup/Ethernet


Is it possible to get an sql injection after importing a sql dump? Is it possible that after I dump a SQL Database created with prepared statements as an ".sql" file, and then I import it again, that the import may be vulnerable to SQL Injections?

Restoring from an SQL dump is an SQL injection.
When you dump a database, you create a script which then executes on your database. This script contains the entire schema, as well as all the data. What you essentially do is tell the database: "Here is this script, execute everything there."
If an attacker can modify your SQL dump in any way, then they can insert, remove or modify any part of the database, since their code would essentially run with DB admin privileges upon restore.


Is macOS installing known bad Certificate Authorities by default? Today I was checking out macOS security and privacy guide, and when I looked at my keychain, I was surprised to find Startcom CA and Symantec CA trusted by default. Isn't this supposed to be vulnerable to MITM?

Apple's reaction to the StartCom irregularities is:

Apple products will block certificates from (...) StartCom root CAs if the 'Not Before' date is on or after 1 Dec 2016 00:00:00 GMT/UTC. (Source)

So to verify certificates that have a 'Not Before' date prior to the one mentioned above, they need the StartCom certificate.
With regard to Symantec certificate authorities they've decided on the following timeline:

Starting August 1, 2018: Partial distrust of Symantec CAs
(...)
Later date: Full distrust of Symantec CAs
(Source)

I guess the 'later date' hasn't arrived yet which is why they still need the Symantec certificates.


Convergence HTTPS - what are the Notary servers? https://www.youtube.com/watch?v=Z7Wl2FW2TcA

What are the "Notary" servers regarding convergence? Who is maintaning the "Notary" servers?

Can someone please explain?

In human words: notary servers are trusted servers that add a "yet another" security level, which actually tries to eliminate MITM (Man-In-The-Middle) attacks.

Notaries act as a mediator to ascertain the validity of a Certificate Authority. Notary servers keep consistency checks on CA root certificates to ensure that a certificate presented by the web-server to the client is consistent with what the Notary server has come to know over an extended period of time.

A "Notary Service" would eliminate the need for operating system vendors to include list of trusted CAs but instead publish list of Notary servers. This option dynamically updates clients as soon as a CA is compromised. The only problem today is that currently, there are not enough "notary servers" available on the internet.

If you're looking for a good example of this type of implementation, you can find it in DNS Root Name Servers which securely maintain Zone records for the internet.

I bet that this practical example is easier to understand than my technical explanation of the definition. ;)


What are safe solutions to protecting important credentials in source code I am doing some Java work for a company that has some code that they want protected in an application that they are giving to their customers.
For example  what if you have information such as FTP or DB login information in the client side application source code?  The login would be visible to anyone who viewed the code, so access to your server is right out there in the open, which means your code on the server would also be vulnerable.  Should the login information be protected by sending information using HTTPConnection/HTTPClient to the server to be processed while using Encryption in transit and sending login credentials to verify request is from a legitimate source.
However wouldn't that also prove to be risky in case the server is hacked/breached, and the Java source would be wide open? (Apparently Execelsior can do server protection with Tomcat applications so there is also that).

I was also looking into various Java-to-Exe programs such as Excelsior Jet, but I also ran into programs that simulate Exe's and apparently have protection such as JWrapper.
I had read in this question https://stackoverflow.com/questions/2244321/does-compilng-java-code-to-exe-e-g-using-launch4java-ensure-code-cannot-be-re
That the emulated exe's are not protected, and still contain Jar files, so I'm assuming the best bet are programs similar to Execelsior Jet, and a program such as JWrapper would not be good then?

Would it take more time for someone to decompile Native code than to try and hack a server (if they even knew what to look for, or that we are even trying to hide anything).  My best bet would be doing server + Excelsior, but the price also goes up if I want to get their Enterprise version instead of Professional.
I am curious what approach people would recommend for safe protection methods.  Thank you.

EDIT:  This question is not a duplicate, because the other question asks about protecting Web Application code from "Web Hosts."
I am asking what the best method of protecting my source code would be.  Whether Desktop, or server based.  The other question could make sense if I was looking at a server solution, but doesn't provide a solution to my need.
Thank you.
EDIT2:  It seems the consensus is that "if someone wants to break, they will..." but isn't there a point to protecting it to stop anyone from just looking at the code?  There are coders who aren't knowledgeable in reverse-engineering, but still can understand code if it's readable.

There are 2 obvious problems with credentials being stored in the source code are:

The source code can be easily reverse engineered and the credentials extracted.
If the credentials are leaked, you would have to change the password on the server, change the password in the code, rebuild and re-deploy

So one option to get round both of these issues is not to have the credentials in the source code at all.  A suitably protected configuration file may be all you need, read in the credentials when needed, use them and then clear out the memory after use.


Do XSS attempts leave any trace on the server? If I do a test with a classic <script>alert(1)</script>, does the website owner see my attempt? Does XSS leave some trace behind?

I will try to build a little server on my Ubuntu with a bunch of websites to test something. Where could I find the evidence in the OS or server?

What can the website owner see?

Basically everything.

If the XSS vector (<script>alert(1)</script> in your case) is part of:

- HTTP headers (including cookies)
- URL (path, query string) except the anchor part
- POST data (including uploaded files)

Then the website owner is able to see it.

If your XSS vector is client-side only, then the website owner may still log it if Content-Security-Policy has been configured to log attacks.

How to test XSS without being spotted?

Don't, unless if you have been permitted to do so.

Run your own vulnerable webserver

Running your own webserver is not that hard:

echo "<?php echo $_GET['xss'];" > index.php
php -S 0.0.0.0:80

This will start a webserver available at http://localhost/.

Known vulnerable applications

Also, check out some projects like Damn Vulnerable Web Application, created to help people learn some vulnerabilites.

Moreover, for XSS, there exists a lot of resources to learn them:

XSS Game, by Google
XSS Challenges


Properties of AES Encryption First of all, I apologize if these questions can be answered using a web search, but I'm sort of a crypto noob and don't know what to search for.

Given N AES encrypted messages (where the message length is much longer than the key length), and the corresponding N decrypted messages (all encrypted with different keys), is it possible to pair up each encrypted message with its decrypted counterpart?
Given one AES encrypted message and its decrypted counterpart, is it possible to reconstruct the key used for encryption if you know the key is 256 bits?

If AES cannot achieve these ends, is there a more suitable symmetric encryption algorithm that can?

Edit: I did some research and found the answer to #2.  This type of attack is known as a plaintext attack, and AES is not known to be susceptible to this type of attack.

1). No, assuming a secure block-cipher mode (e.g., CBC, CTR) was used (basically any mode other than ECB) provided the initialization vectors are not reused.  With ECB mode you could match up messages with patterns of repeated blocks in the plaintext to corresponding repeated blocks in the ciphertext.  See ECB description on wikipedia for more.

Reusing the same initialization vector with multiple messages would completely undermine block cipher modes like CTR that construct a stream cipher out of the IV which is then XOR'd with the plaintext message to create the ciphertext.  In CTR mode with a reused IV (again this is a misuse of AES, IV's are never supposed to be reused), all the plaintext messages will be XOR'd with the same bit-stream -- that the n-th ciphertext will be C[n] = AESCTR-stream(IV) ⊕ M[n] where M[n] is the plaintext message.  Note the following properties of XOR: it is commutative (x ⊕ y = y ⊕ x), associative (x ⊕ (y ⊕ z) = (x ⊕ y) ⊕ z), produces the zero bit-stream when XOR'd with itself (x ⊕ x = 0), and the zero bit-stream acts as the identity with XOR (x ⊕ 0 = x), hence (x ⊕ y ⊕ x = y).  Thus you can simply take any two plaintext messages M[i], M[j] and XOR them with all the ciphertexts until you find two pairs that match.  Note that C[n] ⊕ M[n] = AESCTR-stream(IV) ⊕ M[n] ⊕ M[n] = AESCTR-stream(IV), so at this point you've recovered the AES stream.  (You still don't have the key, but at this point you can decrypt or alter or forge any ciphertext that uses this reused IV).

2). No, there are no known attacks that are significantly better than brute force in terms of computationally feasible (e.g., without taking billions of computers billions of hours to have a minute chance of finding the key).  There are some published attacks on AES, but they either require very weird circumstances (e.g., related key attacks that require 264 messages to be encrypted with 231 keys that are specific variants of the original key) or biclique only give a very small speed up (a factor of ~4 faster than brute force - 2254 instead of 2256), so there are no practical ways to break AES just having the ciphertext and plaintext that are publicly known.


How Data Link layer trailer prevents data from being intercepted and tampers I am reading on https://tryhackme.com/room/introtonetworking, it is talking about OSI model.
It said that Data Link layer trailer can increase security as the data can't be intercepted and tampered. How can it do it?. If it is because of the trailer added in at the end of the data, what stops a man-in-the-middle from changing this trailer too?

The data link layer also adds a piece on at the end of the
transmission, which is used to verify that the data has not been
corrupted on transmission; this also has the added bonus of increased
security, as the data can't be intercepted and tampered with without
breaking the trailer. This whole process is referred to as
encapsulation; the process by which data can be sent from one computer
to another.

In most cases the data link layer does not prevent interception and malicious tampering. Data link layer protocols like Ethernet or PPP usually have a checksum to detect accidental packet corruption, but that's all. This "can increase security" but it does not make sure that "data can't be intercepted and tampered". Somebody intercepting data at the data link layer could simply change the checksum too so that the manipulation will not be detected.
There can be better protection at the data link layer though, even this is not common in typical LAN or WAN. There are actually products which provide L2 encryption. In most cases though application simply do not rely on security properties L2, i.e. they use network layer (L3) protection with VPN like IPSec or use application layer protection with TLS like in HTTPS.


Which type of smart card supports certificates? For an IT security demonstration I want to set up a small demo PKI including smart card authentication based on certificates generated by a Certificate Authority, using a class 3 pin pad reader. For accessing the reader I want to use OpenCS, also because I want to make additional use of it for disk encryption with LUKS.

I have found readers with pin pads which seem to be supported by OpenCS or offer related drivers, however smart cards seem to be problematic as the information given by vendors is always not very specific regarding PKI. I have been unable to identify a clear standard for smart cards supporting this scenario which would allow me to find suitable products, especially usable pairs of readers and cards. While I have found ISO 7816 of which sections -4 and -8 seem to deal with card commands and certificate storage, I can't find any products referencing these sections; mostly ISO 7816 is mentioned in general, which is not enough as it is also valid for SLE4442 cards which are mere (secure) memory cards without any PKI functionality.

Now the question is, does a standard for this exist, or am I missing an important keyword here?

Just to make sure: I know that for good reasons requests for specific product recommendations are not appreciated here, therefore I am looking for help how to identify usable products myself.

Which type of smart card supports certificates?

From the top of my head, 2 cards that are known from having certificates:

CAC (Common Access Card)
PIV (Personal Identity verification)

However, a more broad answer would be "any smartcard that implements PKCS# 11 standard" (which would be the answer for your second question). The PKCS 11 standard determines how cryptographic tokens are accessed. For a CAC card, a library may be provided. For a PIV, you may want to take a look at the documentation NIST provides for it.

Since what you need to do is just do a security demonstration, I would go with the easy path and use a Yubikey instead. It uses the same protocol that smartcads uses (as a matter of fact, it is detected as one) and you can easily find how to manage card authentication certificates for it.


Remote host identification is different on different networks When I ssh to a server - let's call it x.x.x.x - over one network, Network A, I get a message that the remote host identification has changed.

If I use one of two other networks - call them Network B and Network C - to connect to x.x.x.x, I don't get the message.

That is, for the same IP address of x.x.x.x, Network A is giving back a different remote host identification than Network B and Network C.

So my theory is that since Network B and Network C agree, they are correct, and Network A must be giving me the wrong key somehow.

Network A gives the same results over Wi-Fi or ethernet. Network B is my home Wi-Fi and Network C is a mobile hotspot Wi-Fi.

I've rebooted Network A's router, but the different remote host identification persists.

Does this indicate a MITM attack? Is there anything else it could be? What are the next steps?

And to be clear, the problem is not just that it has updated. If I switch my known_hosts to contain the key that network A expects, it works, but then network B and C don't work, and vice versa. That is, they are currently expecting different keys.

The wrong key certainly implies that the encryption is being terminated somewhere other than at the intended host. That might be a mitm attack, it might be a redirection attack or it may be that the network you are connected implements some sophisticated technology for monitoring activity. But recognising a server host in SSH is solely based on the first time you connect to that host - hence it is also possible that network A is giving you an uninterrupted connection while B and C are the compromised connection although less probable than the original hypothesis.

A further possibility is that you are connecting to an SSH service implemented on more than one host. Although all the best practice I have come across (Redhat, VMware, SSH software corp, AWS) recommends using the same server key across all hosts implementing the service, when I was recently implementing such an infrastructure, the architect and security consultant insisted that the instances had to use unique keys (because that's what it says in the CIS checklist).

But the short version is this : we can't tell what is the true connection.

If you login with a password, you could be exposing this to an intended recipient. But if you authenticate using a key pair then an interloper cannot compromise your access.

As to the question of which key is the true key, if you can login using a key pair, and can verify that the host is the one you intended (e.g. your files are in your home dir) then try to SSH localhost and see what key is presented.


Would encrypting a database protect against a compromised admin account? I was discussing with someone ways to prevent data disclosure from a compromised admin account on a database server. The other person proposed encrypting the data at rest within the database. It sounds like a good idea, but I wasn't sure if that would protect the data in this scenario.

My thinking is if the attacker has an admin account, they'll also have the ability to access the encryption key. In a typical configuration, would this be the case? Could the system be engineered so that it wouldn't, while still being practical to administer and use? I could see having the admin provide the key when they log in, but I am ignorant on the security implications of that...

My threat model is as follows: A legitimate admin account's username and password is compromised. Our attacker uses that account to log in remotely and download the database. I understand MFA and other access controls would protect here, but assume they've failed or otherwise been circumvented. I'm merely curious of encryption's effect here.

Now I realize this would definitely come down to implementation specific details, however I am not super familiar with database administration, so I'm struggling to provide a detailed setup for a hypothetical system.

Yes, such a system exists; it's called Application-Level Encryption.  Under that system the encryption keys (or at least the Key-Encrypting Key, or KEK) are only available to the application.  Data is encrypted by the application before being stored in the database, and encrypted blobs are retrieved from the database to be decrypted by the application.

The advantage of this is a sort of dual control - the DBAs, who can perform bulk actions against the entire database without much limitation - can only extract encrypted data.  The application administrators, who hold the KEK, can decrypt anything in the database, but are limited to approved interfaces which may work piecemeal but not in bulk.  It makes abuse of the decrypted data harder to perform and easier to detect.

There are disadvantages as well, primarily the inability to index or search upon plaintext characteristics of the encrypted data in the database.  Also, it requires the application and database be written to support it; unlike whole-disk or whole-database encryption it's not as easy as flipping a switch.


Placing IP address in JSON web token or session cookie I'm relatively new to security and I'm looking to prevent brute force logins on a web application I'm creating.

After doing some research, I decided to go with requiring a captcha after a user attempts too many logins within a set amount of time but I haven't found much documentation on best practices for this but instead a bunch of simple examples and open source packages (which I'm reluctant to use without a deeper understanding of how and why they work).

I already have sessions set up so I was thinking of including the IP address in the session token itself (all of this is encrypted) and cross-checking to ensure that only a certain number of login attempts are made within a certain amount of time before requiring a captcha. My thoughts were that this would have a bonus of preventing session stealing since it would be possible to verify that the IP address of the sender matches the IP on the session.

Would this approach work or does it set off red flags?

I see a few things to think about:

You'd need to make very sure that a login attempt is only valid when
  the client sends you a valid session cookie. Otherwise, the attacker
  can just not send a session cookie and you'll happily generate a
  fresh one for him on every login attempt. That seems to be a hard problem to solve. How do you force an attacker to send you a cookie if he doesn't want to?
Why do you assume that login attempts will all come from the same IP address? What happens if you have an an attack launched from multiple IPs?
What happens if an attacker doesn't try to attack a single user, but tries a whole range of usernames and passwords? This means you won't detect an attack in progress, because there won't be multiple login attempts for any user in rapid succession.

IMO, you can't get around keeping some persistent server-side state about the global frequency of requests to your login endpoint (or in fact to any endpoint), irrespective of who the client seems to be and whether you get a session cookie or not.


Sending database name in request headers I am doing a project with an architecture of single server and multiple database.
Every client request will contain a header containing database name that this request should connect. Is this a good idea for disclosing the database name ?
Is this a security issue ?

This is not a good idea. An attacker could change the database name, supply an invalid one, or put special chars on the database name and possibly exploit a SQL injection. It's possible to do a lot of damage depending on your setup.

You could use server-side sessions, and send only the session token to the user. The database he is connecting to should be stored on the server side session.


What was done to gain a list of home directory accounts? Today some sites were defaced in our WHM/cpanel VPS.
I understand that the common cause of this is outdated scripts/plugins/etc.
However as I was checking the file manager of one of the accounts I saw a .txt containing a bunch of information about the server including a list of usernames of all the accounts inside home directory. I now begin to believe the issue might not be outdated scripts but some security hole in the server itself.

Here's the screenshot of the file:

Note that the root password was never used to login as I am always notified when it happens.

My question is how can a hacker obtain this information? The in-house server management staff where I rent the VPS only said it's due to outdated Wordpress/software but I do not think so. I think this is too much information to be obtained by just an outdated script.

From what I can see, it seems that a hacker managed to gain access to your server - probably through a vulnerability of some sort.

The text file seems like the output of a typical information collection script that one would run after gaining access into the server.

With the information you provided, it is near impossible to determine the exact vector and impact of the attack. You should consult a security firm to determine the scale and impact of the attack, as well as the steps you can take to remedy the breach.

The attacker isn't very careful though, as he didn't erase the text file after his attack.


Web Application Authentication Using Computer Properties Introduction:

I am in the process of building a web-based game that requires user authentication.  The vast majority of other gaming sites utilize the typical username/password method for authentication of users, however, knowing that gamers are typically lazy folks, I have thought about using a new kind of authentication that would instead profile each users computer using parameters such as local IP address, network hardware address (MAC), installed system font names, OS type and version, among other hardware and software properties in order to attempt to create an adequately unique and difficult to impersonate fingerprint that will be tied via hashes stored in a database to a given user account.

Question:

Are there any obvious pitfalls to authenticating users in this manner?

Would this, plus a basic pin number, be enough to protect user accounts from being hijacked by other computer-dextrous users?

This idea originated from this project: https://panopticlick.eff.org/index.php?action=log&js=yes

The browser fingerprint is public information for any site the user visits, so this information should be treated simply as a 'username' and nothing more.

The problem here is if the user changes computers, browsers, or settings they may be locked out of their account. There may be ways around this, but then you veer from your path of simplicity.

The other problem is with a PIN for a password. When using a PIN for a password, the entropy is significantly reduced and would be easily brute forced. Unless you are requiring your users to have a 20+ character PIN, this is highly insecure.

These are major flaws with your idea, though it is novel to say the least. Whether or not you implement this would really depend on the nature of your game, the users, and the required security. It is not a system that I would put ANY trust in, but whether or not trust is required is up to you.