Making SQL/HTML Injection attacks programmatically impossible

Nothing is ever impossible.

But SQL injection vulnerabilities have gone down with ORMs and query builders which prevent the most common mistakes. In my experience, applications which use a secure(ish) by default template engine also have fewer XSS issues.

But the main problems are:

Input sanitation will never solve all issues as you can't sanitize the input for all contexts.
That leaves proper handling at the sink. You'd need to flag all insecure function calls (eg native query), you can't have any variables in your prepared query, and you can't make any exceptions ('the input isn't user-controlled, so it's fine', 'For rare circumstances where [...]', because it will very quickly become unmanageable). This will severely restrict usability for developers.
XSS is very versatile and not all cases can be prevented via templating (eg DOM XSS).

Examples: SQL injection

Let's take PHP as example. You could flag all uses of the various SQL functions (query, etc) and only allow use of prepare. You'd also need to check that no variable is passed to prepare:

$stmt = $conn->prepare("SELECT test from table WHERE x=?");
$stmt->bind_param("s", $test);

But what if you want the tablename to be variable? Or if it's a complex query which you first need to build? Eg:

$filterquery = " WHERE ";
for ($filter in $filterarray) {
    $filterquery = ...
}

$stmt = $conn->prepare("SELECT test from $tablename" . $filterquery);
$stmt->bind_param("s", [...]);

That's something you couldn't allow, as checking if $filterquery is secure is non-trivial. But disallowing variables in queries will severely restrict your developers.

You could use a querybuilder and check that only the binding functions accept parameters (eg setParameter in doctrine), but again you would need to prevent any variables from being passed to other functions such as where). As there are legitimate use-cases for that, it would also restrict usability for developers.

Examples: XSS

With XSS, this becomes even more difficult. First, you'd need to check for all functions which output data and prevent that (echo, print, die, etc) so outputting can only be done via the template engine (this is certainly doable).

But you can't build HTML code dynamically outside of the template, because you can't pass complex variables to it (no way to know if the data is (partially) user-controlled).

You can now HTML-encode the data by default to prevent many cases of XSS. But how do you know if you are in a JavaScript context? Or a src attribute context (where you need to prevent javascript: links)? That's also non-trivial to check (or you need your developers to flag which context the variable is printed in, which is error-prone).

And then there's DOM-based XSS. And maybe you want to allow some users to post a limited subset of HTML (which you can filter, but for which you'd need exceptions in your template).


which password was paired with my gmail address

Responsible media outlets which have obtained the original data set for a password leak will not publicly disclose the passwords. You can go searching around for the raw breach data yourself, but the areas of the internet which would advertise hosting of such data (after it's been pulled from Pastebin and the likes) are likely riddled with malware and exploits.

If your email is listed among those included in a breach specifically associated with your mail provider, it would be safest to assume the email account itself was compromised.

Given that other sources are claiming that the password data may actually be from services other than GMail itself, you should also assume (if your email is listed) that any other accounts associated with your email address are also compromised.

As an aside, you may want to check out http://haveibeenpwned.com. There, you can plug in your email address and see which (if any) public data disclosures it has been found in. Recently, functionality was added which also searches some sources from Pastebin and similar sites.


I'm sure you can add more to secure it to make it the most secure, but another option could be to:

Read in the value as an int64
Check that the value is within the range min_int32 - max_int32
if the value is within range the copy to an int32 variable, otherwise return an error condition.

Your code as it stands (and as you've checked for it) contains a possible integer overflow.  This in itself is technically 'undefined behaviour', and as such, you cannot rely on the compiler or code execution from behaving.


The algorithm PHP uses for coercing strings to integers is documented here. In particular:

  The value is given by the initial portion of the string. If the string starts with valid numeric data, this will be the value used. Otherwise, the value will be 0 (zero).

Your supposition was that:

  I think that with a MAC, for instance "ff6d0...5885d", the PHP juggling will be compared to int(6) since it is the first numerical

But the 6 does not appear at the beginning of that string, it appears only after the non-numeric sequence ff. So the value will be coerced to int(0).

If, however, we have a different hash, say "6ffd0...5885d", the 6 appears at the beginning of the string, so that string would be coerced to int(6).

As you surmised, this coercion can happen during comparison in certain circumstances, as described in the notes on comparison operators in the manual.


Should I use SSL only on my admin subdomain?

This old question popped on the front page and the answer today is clear because...

free Let's Encrypt certificates (even wildcard certificates using DNS-01 challenge)
Mozilla has announced Deprecating Non-Secure HTTP (25 Apr 2015 was before this question!)
Chrome has been Marking HTTP As Non-Secure, all since July 2018 (Phase 3, Chrome 68)

The current best practice is to use TLS for every page & enforce it with HSTS.

...and disable SSL2, SSL3, TLS 1.0 & TLS 1.1 as they are deprecated, too.


By definition, a hash function is not encryption.

  Encryption is the process of encoding messages (or information) in such a way that eavesdroppers cannot read it, but that authorized parties can.

and

  Hash function is an algorithm that takes an arbitrary block of data and returns a fixed-size bit string, the cryptographic hash
  value, such that any change to the data will (with very high
  probability) change the hash value.

Encryption provides confidentiality while hash functions provide integrity.

Hash functions are used alongside encryption for their integrity capabilities.


Password hashing on both client and server : what are the risks concerning hash composition (collisions and reversing)?

If you use the correct hash functions, chances of collisions are negligible. This remains the case if you hash repeatedly. The question Strength of multiple hash iterations? explains:

  There's a catch: increasing n also slightly increases the odds that a random password gives the same result as the right password due to hash collisions, and is thus a false but accepted password; however that remain very unlikely, in the order of n·2−256 for practical values of n, and can be entirely ignored in practice.

I would recommend using a slow, well-known password hashing function, such as PBKDF2, scrypt, bcrypt, or Argon2.


Does end to end encryption have applications/use cases outside of messaging/email?

I think just asking for use cases of end-to-end encryption is a very broad question. But in general: whenever two parties exchange sensitive information which need to be protected against sniffing (and probably also modification) by a third party end-to-end encryption makes sense. This includes for example direct messaging, mail communication, protecting passwords entered into web sites, protecting your online banking, telephony, accessing a remote desktop, management of a remote device in the context of IoT and many many more.

You should also note what end-to-end encryption does not offer. While (almost?) all end-to-end encryption implementations protect the message against modification they often don't provide the assurance that the sender is the claimed one or that no message are lost or that messages got replayed. But these are often requirements you have in end-to-end scenarios and which then need to be provided by additional techniques, like cryptographic signatures or message counters.

And then there are cases where end-to-end encryption does not provide the protection one might hope. For example, if you have two processes on the same machine and owned by the same user then end-to-end encryption probably does not make much sense. It does not protect against a user with same or higher privileges since this user could ptrace the applications to extract the unencrypted data from there. For this scenario a communication using (properly protected) UNIX domain sockets or use of socketpair or pipe offers the same protection but without the overhead of encryption.


Is server exploitable by Shellshock with cgi-enabled only?

You don't mention which server; is it Apache?  At the moment, it appears that an attacker must be able to cause a CGI program to run in order to exploit the vulnerability. Having no CGI scripts would seem to offer some protection. Removing mod_cgi from httpd.conf would offer more:

a2dismod cgi
apache2ctl graceful

The second part of your question relies on security by obscurity, which is always a bad idea.

Here's a list of potential CGI scripts/programs: https://docs.google.com/document/d/1vN2QOG2OZIAHGXDmd5wB8FPi-Hin2GaIlWRJ0RYkTbA/edit  I didn't compile this list, and have not attempted to vet it for completeness.


A backup is a backup, a file is a file. If a file is infected with a virus, and you backup it, then the backupped file contains the virus, and when you restore it the virus is still there. From the point of view of the backup system, a virus is just a bunch of bytes.

This is why recovery after a virus infection is hard: you have to restore a backup which predates the infection.

On the other hand, while the backup will gleefully save and restore viruses, the NAS itself (which is, internally, a computer with its own operating system) should be safe from such viruses, because it will not try to execute the files it copies, and in any case probably uses a distinct architecture (ARM, Sparc... but not x86).


How does WiFi NIC monitoring mode work, if at all?

Your NIC will receive any 802.11 wireless communications that is within range.  Packets that are not addressed to a particular device will be ignored- unless the NIC is in Monitor or Promiscuous mode.

From Wireshark documentation (https://wiki.wireshark.org/CaptureSetup/WLAN):

  A 802.11 LAN uses a "broadcast medium", much like (the mostly obsolete shared) Ethernet. Compared to Ethernet, the 802.11 network is even "broader", as the transmitted packets are not limited by the cable medium. That's one of the reasons why the 802.11 network adapters have two additional mechanisms to ignore unwanted packets at the receiving side: channels and SSID's.

Therefore the NIC is purposely designed to ignore any packets that aren't addressed to that specific device.  This is necessary due to the 'broadcasting' nature of a wireless AP.

Unless a wireless AP could 'beam' a signal directly to a particular NIC antenna, then that may be a way to avoid having to ignore packets.  Although, this would be unlikely considering that it is common to have high density areas with many Wifi networks overlapping and the difficulty/cost in beaming a signal directly to a potentially moving target.


What are the privacy and security risks associated with Intel's Management Engine and AMD's Platform Security Processor?

The new Intel Core vPro processors contain a remote access feature that allows full remote access to a PC at any time, even if when the computer is turned off.  As long as the power supply is available, the system can be woken up by the Core vPro processor, which is able to quietly turn individual hardware components on and access anything on them.

According to Mr Jonathan Brossard, a leading Security Research Engineer, "this is a feature that is documented  and well understood" [...] There is absolutely no reason to believe this is being misused by NSA or whoever.
So practically, the only thing preventing the usage of such 'features' is morality, which is proved multiple times to be lacking on the mentioned organization & Co.

Secret 3G Radio in Every Intel vPro CPU Could Steal Your Ideas at Any Time

Intel's 'Sandy Bridge' Chip to Include vPro Business Features

For the normal web user, there should be no problem, but it is highly likely that certain keywords will trigger events that will cause the listing of the system under 'to be investigated' category.


Encoding is not a mean to ensure integrity. Encoding is here for representation. You encode a string into base64 because it is easier/safer to use the symbols in the internet environment, e.g. URLs where some characters are difficult to convey and interpret correctly afterwards. UTF-8 is used because we need a wide space to represent foreign language characters and other new symbols.

Hashing some content is a mean to verify integrity. If the content C has has D = H(C), you can by transmitting C and D verify that the received message C' verifies D' = H(C') = D = H(C). If it does not, then the message has lost integrity.


Securing data and files so as they won't be openable anywhere else but your own server?

Why do you believe there should be a way? If an attacker can hack your server, they can presumably look at the data on that server - from that point, they could copy the plain data to anywhere else. We know the data must be plain at that point, since your server needs to be able to read it, and you need to be able to access the files (else it's a bit of a black hole). You could encrypt files in such a way that only your specific server can decrypt them - you could even use a hardware security module to make exporting the keys more difficult - but since they have to be decrypted for use, an attacker could simply take a copy at that point.

Think of it as being like a painting - you can protect the painting itself relatively easily, by locking it in a safe, but as soon as you want to display it, anyone can wander in with a camera and make a copy. For paintings, that's less of an issue - you can easily tell when a copy has been made. For digital data, there isn't any difference between the original and the copy, so whatever you can do with the original, you can do equally well with the copy.


How to intercept requests/responses from Smart Phone while surfing internet?

Yes, you can use a router along the way to redirect traffic from your smart phone to Burp suite on your computer.

For example, you can use IPTables REDIRECT target to send it to a local port if you're running an access point on your Burp system to set up a transparent proxy. You can configure a local access point, or connect a router via ethernet and let it provide wireless, getting the traffic naturally through.

Another option if you already have a router setup and don't want to have the router go through your laptop is to intercept requests and send them over an SSH tunnel.

Of course, you can also get traffic via any other man-in-the-middle technique, like ARP poisoning, it's up to you how you'd like to redirect traffic to the Burp workstation.


In Snort for Windows, how do I limit log file size, keep that file, and make another file instance

For snort3 you can do that by adding this line in the snort configuration file (snort.lua).

log_pcap = { limit = 1 }

Unfortunately, I haven't used snort 2 to tell you :(


There are sections of ISO (270002) that refer directly to outsourced development and vendor agreements. The rest pertains to your organization.

Controls that Reference Outsourcing:

13.1.2
14.2.1
14.2.5
14.2.7
14.2.8
15.1.3


Are Truecrypt volumes safe from the government agencies?

Also, how do I prevent a cold boot attack on a Truecrypt flash drive volume?

You don't. The sensitive areas are sanitized if the system is shut down properly, while any cleartext data will still be available and decay exponentially with time. So either make sure that no one will access your system for a few minutes after a shutdown, or re-boot again from a CD using MemTest to perform a R/W test of the whole DRAM. That will completely erase any traces from dynamic memory.

Regarding MemTest and similar tools, you want to perform the fastest test that will overwrite the whole memory. Thoroughly testing 1000 times each kilobyte might result in a 30-seconds test, which, if interrupted at once, will only have overwritten maybe the first 200M of RAM, leaving the rest intact. Testing once the whole RAM will overwrite everything in 30 milliseconds, and with RAM, a single overwrite is enough.

A good UPS can prevent unexpected shutdowns and reinstate the possibility of booting a cleanup CD.

There are also kits to extend the boot sequence. A write-and-check routine could pass for a reasonable precaution against hardware faults, and be a very good countermeasure against coldboot attacks (provided it's not known beforehand). You can make it so, unless you boot with both SHIFT keys pressed, the boot is slightly slowed down - we're talking a couple of seconds here - by a complete DRAM overwrite. Or you can always have an overwrite performed, just in case, without displaying anything.

This will still not protect against an attacker dumping the computer in liquid nitrogen, removing the RAM and mounting them in a different harness.

As for data security, volumes or whole disks are really similar for all practical purposes in your scenario, unless you go to great lengths to ensure "plausible deniability" (i.e. maintain an outer disk with a credible history, which is actually a lot of work). A can of strong acid and an external disk that will fit inside without sploshing might be a better solution.

However, lacking other information, this looks like a webcomic situation.

Try first determining your actual threat model. If men in black may really seize your disks, then chances are that they are able and willing to seize you. In that case, what you really should want is a password that's easy to remember (so you don't accidentally tell a wrong one to the nice guy with the helpful smile), or start thinking along the lines of "cyanide pill".

("Plausible deniability" using two passwords is only okay if you invest an inordinate amount of time in maintaining the deniable maskirovka, and actually the deniable partition is your main drive).

Strong encryption in your scenario looks like either too much, too soon, or too little, too late.


When and why would a penetration test require not just accessing, but downloading a file from a client's network?

This depends on the rules of engagement.  A solicited penetration test is done within a very strict set of guidelines (rules of engagement) so that it doesn't cause more harm than good.  This sets limits as to what can be done; exfiltrating files is pretty risky since they might contain sensitive or regulatory-encumbered info, which is good to know is available during a pentest, but bad to actually start dragging around the internet.  So, always follow the rules of engagement and if they aren't clear to this aspect, have them clarified before you start.

To be specific to your question, if the pentest guidelines state that it's allowable to exfiltrate, AND state that the positive confirmation objective is to obtain a copy of the file, then that's what you do.


Is it more secure to depend on a smaller set of cryptographic primitives?

Hardness problems
All of these algorithms, whether simple or complex, rely on well-known and often simple "hard problems". RSA for example is actually quite complex, involving numerous extensions that are necessary to make it secure, but it is still based on the simple fact that it is easier to multiply two primes than it is to factor a semiprime. Algorithms like DSA (which exploits the discrete log problem) are similar enough that an advance in integer factorization could be used to break DSA as well. AES and countless other symmetric ciphers use the substitution-permutation network. Some ciphers like Twofish use a fiestel network. Others, like ChaCha20, use add-rotate-xor (ARX). All of these designs are well-established, and a breakthrough in solving a major problem will defeat many ciphers, regardless of how simple or complex they are.
How much does complexity matter?
This means that, in the end, the complexity of a given implementation does not necessarily say much about its security. ChaCha20 for example is an extremely simple cipher, so simple and efficient that you can bet that anything faster than it will likely be less secure, yet it is built upon well-known principals (ARX). Serpent is a very complex cipher, with multiple "features" built in to prevent possible future attacks, but it, like AES, uses a substitution-permutation network. It is also extremely secure.
Cryptography and attack surface
Cryptography is not like application security where more complex inherently means more attack surface and greater bugs. Software is traditionally built on the assumption that any bug can break the expectations of the software completely. Ciphers and other cryptographic primitives, on the other hand, are often designed with the assumption that guarantees of the time may not hold up in the future as new classes of attacks are discovered. Serpent was created with this in mind, adding not only extra features, but also increasing the number of rounds.
The world of software security and the world of cryptographic security are vastly different, and established laws in one do not necessarily apply to the other. This includes such important mottos as "complexity is the enemy of security". The only similarity between software security and cryptographic security is that crypto is typically implemented in software. Implementations may be more insecure as they get more complex (compare libnss to libsodium), but the algorithms behind them do not follow the same rules.
In addition, some examples which you claimed as being more complex and thus potentially less secure are actually the most secure. It is based on formally proven mathematical models, not just assumed hardness problems. Regardless of development of new attacks, it is thus always possible for GCM to promise an acceptable minimum level of integrity for a given secure cipher. It being complex says nothing about something as irrelevant as the security of universal hashes over binary Galois fields (which GHASH, used by GCM, is based on).
Use only what you need
If you're trying to decide how many primitives a cryptosystem needs, you're already doing it wrong. In cryptography, you should only use what you absolutely need. Not because extra complexity makes you more vulnerable, but because a system that is designed well does not need more than the situation calls for. This is why cryptographers design ciphers with typically only 128 to 256 bits, rather than something crazy like a megabit. Is a keyspace of 2^10^6 bigger than 2^256? Absolutely, but anyone proposing seriously using or designing a megabit cipher would be laughed at. The same applies to primitives used in cryptosystems. Use what you need, since using extra only demonstrates a lack of understanding of the fundamentals of cryptography.
For example, if you have a need to authenticate data, you need to use authenticated crypto, like ChaCha20-poly1305 or AES-GCM, or an HMAC. If you have no need for authentication (say, because you only care about confidentiality of data-at-rest and nothing more), then don't use authentication. If you don't need it, GCM or poly1305 will only make your implementation more bloated and slower. If you do need it, then absolutely do not forgo it for simplicity. Hell, if you only need to encrypt a single block, and with a unique key, using ECB as the mode of operation is totally fine!
But what do you need? (Obligatory warning)
If you're asking yourself this for a serious project, as opposed to just for education or fun, stop. Use a popular crypto library. The choice of primitives depends on many factors. While the hardness that is the core of each primitive is undisputed, the precise implementation details lead to a lot of gotchas. DSA for example is quite secure, relying on the hardness of the discrete log problem, but it requires a random value, k, for each signature, and if k is in any way predictable or repeated, the algorithm fails catastrophically, revealing your private key. EdDSA on the other hand is based on the same principal, but it is entirely deterministic and requires no randomness to perform signing operations.
If you don't know what you need, here are a few "hard to go wrong" options. If you want to use current and secure algorithms. These are all very fast, and quite secure:

ChaCha20 for encryption. It is uses add-rotate-xor internally and is very fast in software.

Poly1305 for authentication. It has a proven security model and can be plugged in to any symmetric cipher.

x25519 for key exchange. It uses ECDH over curve25519, and uses nothing-up-my-sleeve values (modulo p = 2^255-19).

Ed25519 for signatures. It boasts quite a few security benefits such as side-channel resistance. It uses EdDSA with curve25519.

BLAKE2 for hashing. It's not particularly special, but it's secure and is based on well-regarded security features of the SHA2 family.

ChaCha20-based CSPRNG for randomness. As long as you have a strong seed, any plaintext you throw at it will give you cryptographically secure randomness.

If, on the other hand, you need to use NIST crypto (for example due to regulations, because your marketing department really wants to use the term "military grade", or just because you don't like DJB):

AES for encryption. It has been around for a long time and shows no signs of going away. Fast hardware implementations are common.

GCM for authentication. Like poly1305, it has a proven security model, though it's a bit tricky to implement safely (another reason why you should use a crypto library).

NIST P-256 for key exchange. While it uses sketchy values internally, it's just about the only strong, standardized key exchange technique.

RSA for signatures. It is old and well established.

SHA2 for hashing. Use whatever member of the SHA2 family that provides the necessary digest size or collision resistance that you need.

SP 800-90a revision 1 for randomness. It includes a set of DRBGs (Deterministic Random Bit Generators), of which Hash_DRBG and HMAC_DRBG are considered the least controversial. Revision 1 simply removes the NSA backdoored Dual_EC_DRBG from the list.

If you simply need to use a library, go with libsodium. It is popular and uses plenty of DJB crypto, and is designed to be easy to use. Crytography is hard, and is really the only field where appeal to authority is a virtue, not a vice.


Forgot password and revealing whether account exists

I think this is generally on the wrong side of being unhelpful to legitimate users of legitimate sites - but if your site was promoting anonymity, telling a random web user if a particular email address was valid would be a leak.


What level of PCI Compliance do I need to adhere to if I do not store, but transmit data?

Short version:

Possibly SAQ C, but be careful, because SAQ D is full of people who thought they were SAQ C.  If you gave more information, it might not be long until I nodded sagely and said "ah, yes, SAQ D."

Long version:

If you haven't, you should read the PCI DSS Self Assessment Questionnaire Instructions and Guidelines.

You're not SAQ A.  A is for "Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced." (emphasis mine).  If your server is accepting a card number, then re-transmitting it to your processor, then you're transmitting card data, which is a cardholder data function.

You're not SAQ B.  B is for "Imprint-only merchants", that is, merchants with access to the physical card.  "B" is for Brick & mortar :).

You're not SAQ C-VT.  VT means "web-based virtual terminals", which means that your employee sits with a computer in front of them and a phone and types in the card numbers the customer tells them; the VT acts exactly like the terminal in the checkout line at your supermarket: talks to the processor, gets back a response, doesn't store card data.  If customers are entering data into your web server, then it's not a VT.

You might be SAQ C.  If you're immediately sending auth requests off to your processor, never storing them (like for batch), and don't have any other systems talking to the system that's taking cards, then you might qualify for C. But the kicker is "The payment application system/Internet device is not connected to any other systems within your environment".  You really have to be as minimal a conduit as can be.  This is where the nuance about transmitting-but-not-storing can impact you, by the way.  Storing card data will push you up to D, just transmitting might not - if properly limited.

That leaves you with SAQ D, "All other merchants not included in descriptions for SAQ types A through C".  It's the longest SAQ, which is why a lot of borderline cases believe hard enough that they become a SAQ C.

But even if you're SAQ D, if your processor supports tokenization, you can reduce your scope by answering "N/A" to a lot of questions and listing that as your compensating control.  For example, DSS 3.4, the requirement to encrypt card numbers, can be marked N/A if you're never storing card numbers but instead using tokens.

<disclaimer>
I work for Litle, but you might look into their PayPage + Vault,
which gives you tokenization and allows you to avoid having card
data transit your server.  Recurring payments, too, IIRC.
</disclaimer>


Is this a security risk for us to lost TPM or others to access to reset BIOS ?

A well designed TPM should be pretty resilient to tampering, but a truly determined attacker could try doing something like dissolving the casing and reading information directly off the chip.  It's a pain staking and highly technical process, so probably isn't a likely case in most situations, but if the value of the material is known to be high enough, it could potentially be a risk.  (Though success is not guaranteed and they only really get one shot at it.)

BIOS itself is pretty much a joke to reset in most cases, but would typically result in a wipe of the TPM if so equipped.  It certainly isn't a desirable case to have hardware lost, but the main reason to protect a physical system is to protect data in use rather than data at rest.  If for example, you lost a computer and then it was found, it would be wise not to trust the hardware or unlock it until you had a chance to verify it wasn't tampered with.  Physical alterations could easily pull out the keys when the device is next unlocked.


Disclaimer: I am not a lawyer, this is not legal advice. Please consult a lawyer for any specifics on the follow

The steps to anonymity yourself vary depending upon from whom you want to hide. PayPal or any financial institution wants to know who they are working with (and in some cases legally mandated - KYC). If you just don't want random people to come flame you, "swat" you, etc. Then PayPal is not really your concern because its not like someone is going to call them up and they are going to tell them who you are. However, a government could likely request records from any business to find out who their customers are.

Beyond that, you would also need to protect your identity from the web hosting and domain registrar companies. And also use anonymity strategies (e.g., TOR) when uploading or posting to your website. You will need to publish whois information for your website, but you can use privacy services that will hide that from the public.

Running a business you will likely need to give out a mailing / billing address at some point. You can get a PO Box or mail drop service, but there would still be records about your registration of such with the mail services in many cases.

It also sounds like you plan to setup this website as an "individual", but you may want to take advantage of a corporate structure that offers a high amount of anonymity that at the very least would be very difficult to unravel to find out who you are. You could for example setup a Delaware or Nevada corporation and have that own another corporation etc to create layering. You should be able to setup such structure legally, but it can get expensive and complex. You then conduct all business for the website through the corporation. Clearly, you should find an attorney you can trust.

If your concern is really just PayPal, perhaps you can buy a prepaid card with cash and use that for the purchase transaction. You will still need to give contact data at some point likely though.


They're useful, they're just not useful for building exploits.   They're not useful for determining how buggy a software is for that matter either...The number of CVEs has no strong correlation with code quality.

What they are useful for, is determining, as an administrator, if the versions of a given software package you're using has been patched for specific known exploits, and the potential impacts of exploits that have been discovered. In this way, they can feed directly into a vulnerability management process as one of the many tools that you can use to ensure that your organization is properly managing software security risk.


Security implications of providing users subdomains on my domain?

Yes, they could poison cookies on your domain to execute say a Session Fixation attack.

e.g.

The attacker visits your main website www.example.com and gets a session ID.
The attacker adds some JavaScript to their page at attacker.example.com to set the session cookie at .example.com to be the same as the session ID.
They entice their victim to visit attacker.example.com by sending them a link.
The victim visits the site and has the session cookie set at .example.com level.
The victim later visits www.example.com and logs in. Because there is a session cookie set at .example.com level, www.example.com uses this cookie for the session ID.
As the attacker is sharing that session, she is also logged in.

Whether this is possible on your domain or not depends on functionality. If not this exact attack, others may be possible. Session fixation can be mitigated by refreshing the session ID on login and logout.


Computer monitoring while working at home

It depends on the very nature & purpose of your laptop. Since you mentioned that it is a work laptop, I would not rule out the possibility that the company installed software to log down user activities.

I know for a fact that logging into the company's gmail does not allow them to "monitor your network traffic and internal storage." So rest assured on that.

It all comes down to the software that is installed on the laptop, and the forms that you would need to sign to notify you of the 'monitoring' aspect of the device (most companies must adhere to their own respective legislation)


How to generate a CSR via command line/openssl

My solution:

openssl genrsa -rand large-file-of-quote-random-data -aes256 -out private.key 2048

You will be asked for a password to encrypt the private key. Next use

openssl req -new -sha256 -key my-private.key -out csr.pem

You will be asked for website params; search the web if you need to know the details. You can then use the contents of csr.pem to upload to the cert provider.


If a user changes password should it make all API keys invalid?

I'm going with no, with the caveat that the user should be prompted to reset their API key immediately after changing their password. This is more of a UX/security balance issue than a technical one.

Usually an API token will be installed into a script somewhere, probably not accessible in the moment. Depending on what your data is on the site, it might even be so important that missing API access could cause some major issues. To top it off, the user might not even be changing their passwords due to a suspected compromise but simply standard rotation. I change my passwords regularly but I don't rotate my API keys because they don't sit on mobile devices which can be compromised far easier than my locked down server.

For all of these reasons, I don't think a mandatory key reset is reasonable. If the data is very secret (PII, money, etc) then you could get away with demanding they reset their key to finish but really with anything else I don't think it's worth the user pain.


TL;DR: private keys are called private for a reason.

You can secure private keys by not transmitting them at all.

If you have shell access to the server they are used at, you simply generate them in situ.
If the target device is too weak/underpowered to generate the keys, it is also too weak to use asymmetric encryption (this includes entropy sources). Of course, there are memory-constrained hardwired devices (smart cards, for instance), but you can use a physically secure link to move the keys into them without being connected to the Internet. A rather obscure corner case is asymmetric encryption used in a remote device (read: a space probe or a satellite) but the conditions are unlikely to be met in practice (one key compromised but another secure link still available).
If you don't have secure shell access (SSH) to the target device, you generally cannot securely copy (SCP) the files. Using email to move the keys, even in an encrypted form, draws unwarranted attention to the message and leaves the trail in perhaps dozens of places across the Internet.
Sending the keys means the people at the other end of the channel must trust you and you must trust them. It is not always a good proposition in business and other high-stakes environments (either party can forge communications with the private keys in hand).

EDIT: For the stated use case of private keys for a hosting provider, you are still better off generating them in place.


This link provides download for various password dictionaries:
https://wiki.skullsecurity.org/Passwords

This include
- 500-worst-passwords
- rockyou
- phpbb
- conflicker
- and more!

You can find hundrets of these via a simple google search

You can use these files with the --wordlist parameter (assuming you are using command line).
See the John documentation for more information for how to use John.

I hope this answers your question.


How to make a website patch their poor security?

So there's a couple of options open to you potentially, depending on the country you live in, however first a note of caution.

You "tested" the site and then reported your findings.  In many countrys if the application owners want to make out that you "hacked" them, they could do that, and it may be bad for you.  I say this just so you can weigh it up when you're considering taking other actions. I'll leave aside any more legal stuff on hacking as it's been covered in other answers.

Basically the main ways to get them to address this would either reporting this to a regulator/government body who are responsible for data protection (e.g. in the UK, the information commissioner), as it seems that they're not taking appropriate measures to protect personal data which they are processing.  This may get them to fix it if the regulator contacts them regarding the problem.

The other option would be to try and attract bad publicity to the site, by publishing the details of the vuln.  This may have the desired affect, but be aware a likely side affect is that they could take legal action against you (again depending on the jurisdiction, they're attitude to security etc)


Is it expensive for ISPs to store browsing, text and call logs?

This question is highly subjective.

It depends on what you consider expensive.
It also depends on what exactly they are required to log.

If they just log texts, call times, and internet connection logs ... that is relatively trivial.

If they have to record full phone conversations and all internet traffic packets ... it could be come very expensive ... but they would just pass it off as part of the billing for there service.


Use the server's key to digitally sign the HTML content it delivered?

From what I'm understand, what you're trying to do is to verify, after you are sure that the page arrived from the network untouched (since it's TLS), that it has not be modified by any client-side malware.

Since it's a client-side malware, it's safe to presume it can change anything he wants on the client side, after the session is decrypted from the TLS layer. Then, there is no way for you to be sure the data is intact : even if you add a cryptographic signature, the malware could just change your server's public key in memory and resign the HTML, or simply bypass the signature check.


Security Implications of using Base64 Encoding with Encryption

As long as the key is converted back into the binary format before use, the bit-dilution caused by the base-64 encoding will be undone.

However, if you're passing keys around an application be careful of how you do it.  Wipe text buffers, minimize transits between methods and applications, etc.


Is the following e-mail fraud technically possible?

Plenty of things could have happened.

To start with, emails which are not digitally signed cannot be trusted:

they can be tampered with in transit (not very likely when the exchange is between two large providers)
the sender can simply fake the email (such an email may not be accepted by the recipient's system and one could check the path it took to reach it (if the headers were available, which is usually not the case with webmail providers))

So we do not know who sent which email (B, C or someone else). This is not interesting enough for an authority (police or other) to get involved so the hope to find out is close to none.

Now the sending itself: we do not know whether B's account is secure. Maybe C got access to it. From there on he can do plenty of things, including catching outgoing emails, redirecting incoming ones etc.

So to summarize: we do not know what happened and will not know, even by looking closely (especially if this is webmail from larger providers). The only reasonable thing which B can do is to change his credentials and review his filters (in the webmail system). And your friend to use an escrow system for payments, if available.


Is it ok to cut some digits from the front-face of a credit/debit card?

A credit card contains the card number (also known as the PAN), it multiple ways. Even if you remove the raised digits, some thieves may had a card reader and can get this information off of the card swipe. If there are shops where they are using a rub method, they will need all of the digits anyway. You could just tell them the missing digits and they can write them down if its all offline. If they have a digital terminal, they will be typing in all of the digits one by one anyway and technically don't even need the card.

Old terminals without a chip and pin system can still work with a newer card.

Instead of mitigating the risk of your credit card being stolen, it might be more practical to look into the transference or risk. After being robbed, can you get to a phone and cancel your cards? Your card should have fraud protection to reverse the transactions. I cannot comment on whether the requirements are different in asia, but you should be able to have fraudulent charges reversed and a new card sent. You could also look into credit monitoring and other fraud protection services.

Edit:

I have also seen technology which replaces raised numbers with a digital display which you have to activate with a 4 digit pin on the card itself. I only recall two banks implementing such a technology. This doesn't appear to be exactly the same thing, but maybe in the future it will become more popular to have cards that dynamically re-write the mag strip like this or like this. Maybe you can get a new card from a bank with bleeding edge tech.


Are there any examples of when personal email data can be brought into a lawsuit involving a corporation?

In the United States, generally anyone can subpoena anyone or anything as part of the "discovery" process.  It is up to the presiding Judge to decide whether or not this is relevant or allowable.

In a civil action, as opposed to a criminal one; some typical protections (e.g. 5th amendment protection against self-incrimination) do not apply.  Thus, it is far easier to compel disclosure of information during a civil case than during a criminal one in the United States.

So to answer your question's points:

1) Yes, they would be open to a subpoena; this is distinct from a "legal search" conducted by law enforcement personnel.  The party receiving a subpoena would be compelled to hand over the information in an unedited/original form.  In a criminal case however, yes, law enforcement would be able to subpoena the provider or the individual to obtain this information for investigation, or just seize it themselves.

2) Yes, the information on these devices could be subpoenaed if it is relevant to the case or controversy at hand.  The court could order the devices analyzed by a forensic analyst, or simply they be turned over, etc.

3) Corporate policies do not trump the sovereignty of the state.  As Max Weber famously stated, "The state is the entity with the monopoly on the legitimate use of force."  Since force majeure, in the form of a subpoena carrying with it threat of criminal charges like contempt of court, trumps any corporate policy -- no policy could prevent a court from ordering disclosure of your information as long as it resides within the court's jursidiction.  If data relevant to a court case is subpoenaed, and the court grants such a request, no corporate policy can defend you.

I am not an attorney and you should consult a knowledgeable attorney on these matters when devising corporate policies and strategies for BYOD and measures to mitigate risks of discovery actions.


Is there any security threat with open WiFi connection?

Unprotected Wifi networks, particularly in public places, are most certainly a threat. This is because you are connecting to a network without knowing who else could be on the network.

'Free Wifi' provided by cafes, restaurants, etc serve as excellent places for harvesting passwords.

The attacker will perform a Man in the Middle attack, typically by employing ARP Cache Poisoning. At that point, the attacker can read all plaintext passwords, including unsecured email (Email that does not use TLS), unencrypted ftp, websites without SSL, etc. Not to mention they can see all your google searches, all domains that you visit (encrypted or not) and so forth.

And they got to this point without putting in any real effort, ARP Cache Poisoning and Packet Sniffing are easy. A more advanced attacker might set up an active proxy on his machine to perform attacks such as SSL Stripping, which would give him access to all sites you visit, including HTTPS. This means he now has your PayPal, Facebook and Twitter passwords.

Moving on, an attacker might target your machine directly, if you have not updated your software in a while, is it likely that he can spawn a shell with Metasploit and download all your files for later analysis. This includes any saved browser passwords, authentication cookies, bank statements etc.

TL;DR: When connecting to a network, you are exposing your device and all your traffic to all other users of that network. In an open WiFi this includes the girl sat across the street in the back of a van with a Kali laptop and a GPU array. Update your software and don't log into anything sensitive without using a VPN.


There are indeed two properties to a password:

Complexity (number of possible characters in each position)
Length (number of positions)

The 'randomness' of a password is simple to calculate: complexity ^ length, where ^ is exponentiation. As you might know, changing the exponent (the length) makes the number much larger than changing the base (complexity).

For example, a random password using 6 characters, consisting of a-z, A-Z, and 0-9, has a complexity of 62 (26 + 26 + 10) and a length of 6, making 62^6= ~56 billion possible passwords. It is well-known that 6 characters is very insecure for most purposes, even when randomly generated.

For randomness, more is better, up until about 128 bits of entropy. A little more than that helps buffer against cryptographic weakenings of algorithms, but really, you don't want to memorize 128 bits of entropy anyway. Let's say we want to go for 80 bits of entropy, which is a good compromise for almost anything. (Unless you use a password manager, which you should. In that case, just generate 128-bits random passwords and you're good.)

To convert "number of possible values" to "bits of entropy", we need to use this formula: log(n)/log(2), where n is the number of possible values. So if you have 26 possible values (1 letter), that would be log(26)/log(2)= ~4.7 bits of entropy. That makes sense because you need 5 bits to store a letter: the number 26 is 11010 in binary.

A password with a complexity of 62 needs 14 characters to reach our target of 80 bits:
log(62^14)/log(2)= ~83.4 bits of entropy.
Example: c21FApmUsptwfd

If you add all possible ASCII symbols, you get a complexity of about 95. These passwords are annoying to type, even harder to remember than without symbols, and you still need 13 characters:
log(95^13)/log(2)= ~85.4 bits.
Example: ~2YPCi.%$6u,.

If you add words, your password becomes much longer, but is slightly easier to remember. The calculation is similar: number of possible elements to the power of the number of elements. If you have a dictionary of 7000 words and pick 6 random words, you have 7000^6 possible combinations. That is:
log(7000^6)/log(2)= ~76.6 bits of entropy.
Example: cardigans Malthusian's acorns glows unconfirmed uncluttered

You can combine them: if you have four random words and three random digits in between, you have 10^3 * 7000^4 possible values. Again, the entropy calculation:
log(10^3 * 7000^4)/log(2)= 61.0 bits of entropy.
Example: foreshadow3sectionals2palm6deliberating

It is simple to use the math and make a table of possible combinations/lengths/complexities and compare their strengths. You can mix properties until you find a combination that you like, and check that it gives you enough strength. But to answer your question generally: length beats complexity.

Finally, it should be noted that the example you used is not as strong as N random words: the 6-word sentence "OneDayIWentToWalk" makes sense. The 6-word sentence "OneIDayWentToWalk" does not make sense. Someone guessing which passphrase you used can eliminate all the possible nonsensical sentences and try only the grammatical ones. That reduces the number of guesses required by a lot. This question at the Linguistics StackExchange explores the randomness of grammatical phrases. (Credits to Tezra for sharing that link.)

Note: this answer uses parts from another answer I posted in a different question earlier today.


What are the risks of accepting URL param for automatic redirection?

Someone could pass a link to //xss.com/malware.php, by encoding it as https://www.example.com/login.php?previous_page=%2F%2Fxss.com%2Fmalware.php. To prevent this, you could pass the path from the site root as the parameter, so you would pass only dashboard.php. Then assemble the full link on the server side.


What can a site visitor do with a 777 file on my web server?

Servers are not written in a way to automatically modify a file just with a simple POST or PATCH method, a security feature, to be sure, so 777's biggest threat is that it does expose read-access to potentially sensitive data. Depending on the server configuration, a 777 file could also be executable, though most server configurations limit execution to "bin" directories as an additional safety feature (e.g. "cgi-bin"). Without ftp, ssh, telnet, etc access, the file is still effectively read-only.

That said, you shouldn't rely on this, and always make sure you chmod your files correctly to avoid any potential complications. The security implications are directly related to the values inside the file, of course. If it's just a list of blacklisted IP addresses, probably harmless, but if it has server configuration values, passwords, etc, that would be an obvious security concern.

In summary, 777 by itself is "mostly harmless," but it really depends on the purpose of the file as to the importance you should place on protecting the file.


You need to sanitize the content before embedding it in your HTML output, otherwise you are guaranteed to have XSS vulnerabilities in there.

Please do not reinvent the wheel, as there are great sanitizers out there, that you can utilize. I highly recommend using DOMPurify, which is also integrated in several widely used JS frameworks to reliably protect against XSS. It aims at being secure by default, but also offers capability for configuration and fine tuning.


What to do when asked for a weak password

As discussed in the comments section, password based security is very minimal for banking, as it is worth the effort for a thief to try to steal your password. They basically only have to infiltrate your browser and log your entries. Furthermore, if this is achieved, they have full access.

Approaches such as hashing or other algorithms do not really matter, as you still will be typing in a password that has to commit to the set limits. Thus, you are really only making it harder to remember for yourself, but someone trying to bruteforce -- although it still is a lot of characters for bruteforcing -- still has to do the same effort.

We also discussed other approaches, such as security tokens -- which I personally prefer -- and SMS-based one time passwords. The idea of the former being that you must have your card at hand, and use this to set a signature. However, most non-connected implementations work by signing a number (hash) that most users cannot relate to the action that is about to take place, so a smart attacker may try to fool you by changing the numbers on the screen and the actual numbers. This is where the connected token comes in, which uses its display to show you the complete action you are about to allow, which is probably the most usable secure method out there at the moment. However, I have no idea on banks supporting these techniques in your region.

Finally, with banking security, auditing is most important. Check your statements for crazy transactions and report those as soon as possible. This still is the best approach to banking security. Recall, for example, that credit card fraud is not so hard, but recalling transaction is not hard either.


Is there a secret-sharing public-key-encryption-based service?

Citrix ShareFile is one such service. It is primarily used for transferring large files, but you can encrypt them.

It's not free, though.


Understanding nibbles & encoding using owasp EnDe tool?

Although your question is far from clear, what apparently happens in your encodings is rather simple to unravel. See your example string abcdwxyz. When encoding in ASCII, this yields 8 bytes, with hexadecimal values: 61 62 63 64 77 78 79 7a.

Now, for each byte, take the left hexadecimal digit: it is a character which itself has an ASCII code, which can be represented in hexadecimal. For instance, 61 begins with 6 and the ASCII code for the character 6 is 54 -- that's 36 in hexadecimal. On the other hand, you can take the right hexadecimal digit, which represents a numerical value between 0 and 15, and represent that value as an hexadecimal digit (using digits 0 to 9 and letters A to F). In other words, you keep the right digit unchanged, except that you possibly normalize it to uppercase.

If you apply these rules, then 61 becomes 36,1, 62 becomes 36,2, and so on... up to 7a which becomes 37,A. And you end up with your first "encoding".

If you do the same process, but reversing the roles of the left and right hexadecimal digits for each byte (i.e. you keep the left hex digit of each byte unchanged, and you convert the right hex digit to the hexadecimal representation of the ASCII value of its character), then you obtain your second "encoding": 61 becomes 6,31, 62 becomes 6,32... and 7a becomes 7,61 (the ASCII code for a is 97, aka 61 in hexadecimal).

For the life of me, I cannot fathom what possible use these "encodings" could have.


Set-uid script wrappers, `system(3)` shellshock and Bash Function Import from Environment

Such setuid wrappers are dangerous regardless of whether the script interpreter is a fixed bash, an unfixed bash, or some other shell. Reason being that script interpreters are impacted by many environment variables. Oft-cited offenders are PATH and IFS. This is the reason why sudo resets the whole environment to sane values (since shell authors are invariably creative, you cannot achieve security with just a blacklist on a few "known dangerous" environment variables; you have to kill the whole lot).

To abuse an overused metaphor, FIE is just the tip of the iceberg, not the actual ice block that rips apart the ship's hull. Environment variables are the issue, because they are a covert, indirect channel that propagates through calls, and may impact functionality in lots of ways (e.g. you could change the behaviour of the memory allocation routines by activating the "debug mode" through environment). For setuid binaries, the kernel clears the worst case (LDPRELOAD) but, really, all environment variables ought to be cleared, with the possible exception of the LC_* variables (for setting locale-dependent behaviour -- and even that is highly debatable).

Of course, patching the kernel to clear the environment whenever a setuid binary is invoked is bound to break things... Even OpenBSD, despite their "all your security belongs to us" stance, have shied away from actually implementing such a drastic change. Instead, they rely on documentation:

  Don't trust your environment ! This involves simple things such as your PATH (never use system with an unqualified name, avoid execvp), but also more subtle items such as your locale, timezone, termcap, and so on. Be aware of transitivity: even though you're taking full precautions, programs you call directly won't necessarily. Never use system in privileged programs, build your command line, a controlled environment, and call execve directly. The perlsec man page is a good tutorial on such problems.


Honeypot tricking my android device to connect

Does the honeypot have a singular SSID, or is it more like the question where he's constantly changing the name so that phones automatically connect?

If it's a singular SSID, what's the name of it? If he's named it a common hotspot name like "attWifi" or something, your phone might be seeing it and automatically thinking it's a public hotspot. There could also be a feature that allows the phone to connect to unsecured networks when a known one isn't available.

Jamming his router is illegal, but kicking people off of it isn't. An overkill solution would be to setup a wireless device with tools like the airocrack suite. Just script it so that if your device connects to a network that isn't whitelisted, it'll kindly use aireplay to send it a deauth packet.

Unfortunately without more information, we can't be of much help


How are two systems able to set up a secure SSH tunnel over a public connection?

Though the question is about SSH, the same concept as in SSL apply, so see this answer which explains it all.

Short summary: it's magic. Asymmetric cryptography magic, to be precise.


How to prevent XSS when inserting untrusted data into a textarea?

It's not enough. One possible bypass:

</textarea ><script>alert(1)</script>

This works because of the extra space after textarea.

You could adapt your filter to catch this as well. But I wouldn't recommend it because the approach is already flawed.

If you do not need to allow a user-supplied subset of HTML to be rendered (which isn't the case here), then the proper protection against XSS in a HTML context is HTML-encoding:

$message = htmlentities($message, ENT_QUOTES, 'UTF-8');
echo "<textarea>$message</textarea>";

Now the message will be displayed as intended, but there is no possibility for XSS.


Is using an old Android phone for 2-factor authentication safe?

It's perfectly safe if it's off the network. Something like that is an excellent use for an old device that's completely off the network -- as long as it stays in time sync.


How to source training data in ML for information security?

The domain problems in cybersecurity are too-narrow to willy nilly try to apply AIML or DL to.
Not saying to throw data science out the window. Saying you need way more domain expertise to make it go.
One excellent application of data science to the cybersecurity field is to understand the indicators, or IOCs, and how they are sighted (last seen, etc) in memory, on disks, and in network traffic (and positioned where in the network traffic relative to the sources, destinations, and passthroughs -- just like any dataflow). Instead of levering ML or DL, I would instead suggest to focus first on graph algorithms. Understand the relationships of these indicators and their interpretation as time series data

A File "Hash" (e.g., a SHA256 checksum of a file or a section of memory or network traffic of a process). Here is an example of the domain problems associated with cybersecurity. The way the our signatures (e.g., Yara rules) work on-disk vs. in-memory vs. in network traffic are obviously different code and data, and code and data paths. Parameters or arguments to processes also matter especially for script code
an IPv4, IPv6 address or path, and its associated network attributes such as BGP-4 ASN if registered with a Regional Internet Registry (RIR). There is often a history associated with these objects and narrowing into them may require understanding complex RWhois and SWIP registration processes
an FQDN, or Fully-Qualified Domain Name -- sometimes hostname and with Windows Server Forest/Domain bits, perhaps older namestays such as NetBIOS or MS-RPC Named Pipes. Cloud stacks such as Azure AD are changing this nomenclature as well, moving to tenants, subscriptions, resources, et al. A set of Whois records identifying each unique Internet Domain Name can come with its own set of relationships including a rich history of timestamps, owners, name servers, and email addresses
A credential, often an email address, e.g., bertrand.russell@math.onmicrosoft.com but also a cred user/pass pair, i.e., bertrand:MathIsK00lB00ksRul3 if known (often if compromised)

As a hint of what would be possible, check out the work here -- https://threathunterplaybook.com/introduction.html -- which pivots nicely off of the fields (and parsing languages) from Azure Sentinel and M365/Azure data models


What conditions allow an attacker to write a cookie?

One interesting scenario is HTTP vs HTTPS cookies. With an HTTPS site, man-in-the-middle attacks are not normally possible. However, if the user requests an HTTP site, a MITM attacker can tamper with the communication, include an iframe reference to the domain they want to target, and within the iframe write to cookies. Although this communication is over HTTP, cookies set here affect the HTTPS cookie store. I wrote about this some years ago.


Is it possible to inject HTML into image to provoke XSS?

I'm pretty sure bstpierre was talking about a situation, where you let users upload images to display in a gallery and furthermore you display meta-data about that image taken from EXIF tags.  If the EXIF tags were specifically constructed with malicious html tags, and there was no input sanitation (e.g., escape characters like <, >, &, so they are rendered in the page like &lt; &gt;, &amp) you could conceivably use them for an XSS attack.  Again, it is not a problem if your web app sanitizes all user-input including extracted tags from image files.

bobince was talking about a few totally different things; the closest being that someone uploads a file - say fake_image.jpg but instead of being an image, the content is actually a html file.  By content sniffing, he meant that some browsers, when you click to open up a page http://example.com/fake_image.jpg can figure out that fake_image.jpg is not an image but instead a html file and will display the html page in the file.  Thus, the uploaded html file (with an image file name) could be used in an XSS attack.  For this attack to be useful, you have to have a browser that allows this sort of content-sniffing, and then you have to go to the URL of the image (not just have <img src='fake_image.jpg'> embedded in the page).


Are browsers still vulnerable to Cross-Site Cooking?

It is believed that browsers can deal with this issue today. However, this is not only the problem of browsers and they are not the general cause of this failure. But to make my answer complete, I would like to direct you to good blog post that is written by Michal Zalewski: http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html.


Cisco FirePOWER estreamer python client SSL Cert issue

It seems that the error message for eStreamerKeyError indicated the .crt file as the source of the issue when it was actually the private key file.

This ended up being the correct command for the private key:

openssl pkcs12 -in test.pkcs12 -out test.pem -nodes

I also had to download the SSL cert:

openssl s_client -showcerts -connect 172.16.10.42:443


How to approach ruling out that past developers are backdooring my website?

There are infinite many ways a developer can place intentional and unintentional backdoors into code. When the developer is skilled, they can hide them well and/or mask them in a way which appears like an unintentional mistake. A complete code-review is the only way to achieve reasonable certainty that further backdoors are unlikely to exist. But there is really no sure way to completely rule out the existence of backdoors.

When you are in a hurry, you could at least try to rule out the most obvious things before you start investigating the complete code line-by-line:

Take a look at the login and authentication code - this is the most obvious place to have a magic parameter, universal password or hardcoded credentials which allows one to log in without a valid account.
Check if there are any scripts in the codebase which don't appear to be referenced anywhere - they could be a hidden control panel or similar.
When email messages in particular are a concern, grep the websites codebase for those functions which send emails in your programming language. You could also monitor the webservers traffic for outgoing SMTP traffic to notice any emails which do not match the format usually sent by the application (when it is supposed to send emails at all).

By the way: This might also be a topic for your legal department to address. Backdooring the application is likely a breach of contract and might even be a felony in your jurisdiction.


The nmap plugin that you are using only tests against snooping, you can see if a user (using this DNS server) has performed a DNS request.

This is tested, using nmap, in 2 possible scnearios:

Timed: it will measure the time difference between a cached request (faster), compared to a normal DNS request (slower).  This way, it knows if the domain has been cached and thus "visited" before.
Recursive: If your DNS support this, a DNS request with the RD flag set to 0 will only be responded to if the domain is cached on your DNS server (and thus, visited before).

The best test is to test against domains that are probably used by the target domain.  Nmap by default tries the top 50 most popular domains, so that might be a good bet.

From a command point of view, the map page says that the timed attack can only work once reliably, since it inserts data into the DNS cache.  I'd say try with the default settings

nmap -sU -p 53 --script dns-cache-snoop.nse --script-args 'dns-cache-snoop.mode=nonrecursive' 1.2.3.4

Hope this helps!


Verify senders of earlier emails in chain

If you get a mail with was forwarded as a message/rfc822 attachment with all headers instead of inline it is possible to validate the DKIM signature and check the result against a DMARC policy. For other kinds of forwarding (i.e. quoted, prefixed...) this is not possible. It is also not possible for replies since none of these contains both the necessary DKIM-Signature header and the unchanged mail headers and body which are covered by this signature.


Does Linux “Dirty COW” Exploit allow for escalation outside a virtual machine?

You are looking at two different vulnerabilities.

Dirty Cow is a privilege escalation in the operating system. So, if  your VM is vulnerable, that means it's possible to get root privileges in the VM's operating system, not in the host system.

In order to be possible to access the host, you need a vulnerability in KVM or QEMU that allows you to escape from the VM sandbox.


Best way to store site-wide password encrypted on server?

I'm surprised that there doesn't seem to be a canonical question and answer or at least a duplicate of this on this site - but a quick search failed to turn up anything relevant.

(There is no OS independent answer to this question - but I will address Unix/Linux for various reasons not worth going into right now).

In order to use the password it must be accessible in an unencrypted form to your application. That means the user account under which your application runs and root will have access to the plaintext. Most likely it will also be present in backups of the system, and definitely will be present in VM snapshots.

So it is impossible to be completely certain that the password will not be exposed. That means that you (or the other relevant system administrators) should be taking taking steps to mitigate this. The obvious ones are:

1) Password Rotation this limits the window in which a captured password will be of any use to an attacker. In most cases, to get a seemless change, you need to alternate between two accounts - so one is in use while the other is getting changed. Surprisingly few people bother with this.

2) Token based authentication - the password bootstraps a change of single use tokens (and is immediately forgotten by the client). Deployment of this is even rarer.

3) The use of a machine identity is growing in popularity (due to the availability of the service in clud environments). To avoid a plaintext password being stored on a computer (or an equivalent substitute such as a private key) the infrastructure vouches for the client, e.g. by providing a signed attestation which can be presented in lieu of a password. This generally requires custom software at client and server to handle the authentication.

Given your current constraints then these are not very practical solutions - that you only have a single account, using off the shelf software and no control over the server you are trying to authenticate to. A further consideration is that, using PHP, you need a low overhead on whatever mechanism you choose to store the password. Although not ideal, the most practical solutions I can think of are:

4) use the Linux kernel key storage (assuming this is linux). AFAIK, there is not a PHP extension for this - so you'd need to run an external program to retrieve the password each time.

5) store the password in a file on a ram drive (with appropriate permissions). You could use shared memory instead but the tools for interacting with the file and its contents are more limited.

6) Store the password in the webserver runtime memory and pass it to PHP at runtime as an environment variable

7) store the password in an encrypted filesystem - there's a lot of choices here, but encfs is probably the least painful and easiest to integrate with the backup.

Note that the first three require that you provision a method for injecting the credentials at boot time (not sure how you would do this for the webserver), while encryption requires that you provide a decryption key at boot time.


Azure VPN Gateway Client - Reported as Win32/Detplock

It is a false positive. Just simply ignore the message from Windows Defender and run the client tool anyway.


How some sites prevent cross-site requests through referrer although there are redirections allowed

Now the question is how then I can access twitter.com for example from google search

Twitter is conveniently ignoring the referer header because you are landing on a unauthenticated page twitter.com. Cross-origin request can lead to CSRF when the session is created and request is leading to a state change. https://twitter.com/i/flow/add_phone from here, the state of the parameter will change with post request submitting your password first, followed by entering your phone number. When the google is redirecting to twitter, the referer header is sent but twitter does not check it for protection, since no csrf risk is considered in that case.
Kindly note, referer header shall not be used as only method of preventing cross site request forgery because it can be bypassed based on how it is validated.


Well, frankly, in general your list looks like a made-up set of automatically generated marketing buzzwords, sometimes completely unclear or unrelated to cyberattacks ("direct" anyone?). However, the author of the said report claims to have taken the list from Akamai, which probably gives us a clue to what "origin error attack" means.

Akamai is a CDN provider. Though the paper is dedicated to DDoS attacks, and Akamai DDoS Mitigation is technically completely unrelated to Akamai CDN network1, it's still the same company, at least in terms of PR and marketing activities.

Here's a short summary of CDN terminology. A content delivery network consists of edge servers – devices which serve a content to clients (e.g. Web browsers). The content an edge server maintains is retrieved from an origin server and distributed to all edge servers, or a subset of them, in a way specific to the particular CDN. An origin server is the server (operated by a customer of the CDN) which is hosting the original content, the latter being then copied, cached and distributed by a content delivery network.

In case of a cache miss, i.e. when a request is received for a piece of content which is missing on an edge server, the latter requests the content from the origin server. An origin error is the message returned to a browser by an edge server in case there's no such content available both in the edge server cache and on the origin server, under most normal conditions2, together with a 404 "Not Found" HTTP status code.

A typical (botnet based) application layer DDoS attack towards an HTTP application may have little3 impact on the availability of the said application in case all the Web resources requested by a botnet are cached by a CDN, and the latter is powerful enough to handle all the requests from the botnet. However, an attacker may choose to request only those resources from the CDN which are guaranteed to be absent on the origin server (e.g. random resources from a non-existent directory). This way, all the requests from a botnet would result in cache misses, and would all be simply proxied to the origin server which hosts the HTTP application, rendering it unavailable for legitimate users due to heavy load.

It is more or less suitable to call this method an "origin error attack" if anyone wants to give it a name.

A modification of such an attack is requesting resources that do exist both on edge and origin servers, with a random query string, e.g. https://example.com/?jhd=370 instead of simply https://example.com/. Some CDNs treat such a request as a cache miss and forward it to the origin server, as HTTP specification suggests. Others can be configured to strip query strings when a static content is requested, or deny such requests at all. Thus such an attack method, while being rather efficient against a dynamic Web site, might impose little impact on a static one.

**

Update (26.03.2020): there's now a conference proceedings paper which describes the attack in more detail.

1 Akamai Technologies maintains its Internet presence as autonomous system 20940. Akamai DDoS Mitigation (formerly Prolexic) is AS 32787. Akamai Technologies has acquired Prolexic in February 2014, however, as of March 2020, former Prolexic network seems to be still only loosely related to the main Akamai network:

Peering policies and locations available for peering are completely different for CDN and DDoSM networks;
Routing policies for CDN and DDoSM are also completely different.

2 The 404 status code is returned in case the edge server is able to reach the origin server, but the origin server itself responds with the 404 status code. In case the origin server is unreachable or doesn't respond to requests, 502 Bad Gateway and 504 Gateway Timeout status codes are often returned, respectively.

3 In case all pages of an application are cached by a CDN, a DDoS attack may still have an impact on the application's availability, but the impact is limited to the infrastructure issues, for example, DNS server performance in case the botnet nodes resolve the name of the victim themselves, or OCSP server performance in case bots are built on top of headless browser instances, and so on.


Why are chips safer than magnetic stripes?

You can't clone the chip.

A magnetic strip holds a secret number, and if someone knows that number they can claim to be the owner of the card. But if a bad guy swipes the card, they then know the number, and can make their own card, i.e. "cloning". This has turned out to be a major practical problem with magstripe cards.

A chip also holds a secret number. However, it is securely embedded in the chip. When you use the card, the chip performs a public key operation that proves it knows this secret number. However, it never reveals that secret number. If you put a chipped card in a bad guys machine, they can impersonate you for that one transaction, but they cannot impersonate you in the future.

All of the above assumes that the implementation of the chip is good. Some chips have been known to have implementation flaws that leak the secret code. However, chip and pin is now pretty mature, so I expect most of these issues have been ironed out.


Help me with my BitLockered drive (forgot 3 digits from the password, lost the recovery key)

There isn't much you can do other then trying to remember very hard what these 3 digits are. There is no known way to circumvent BitLocker in general. If you type in a wrong password several times, the system will report the "Too many PIN entry attempts" error message and then your only chance is the recovery key.

While I understand that you might find this regrettable, one should also not forget that this sort of security is the whole point of BitLocker.


What is the probability of a desktop machine being compromised?

There is no "hard statistics" on desktop compromise. There is only case study and research into limited contexts where compromise has occurred. But that data is not useful for making inferences in other contexts.

Case studies and "vendor propaganda" study a limited set of systems and compare the historical results. That's great if your system is in the same context, have the same users, threats, processes, etc. etc. They don't tend to include systems in similar contexts that have a different result because that just gets confusing as a narrative.

There's a reason why you can't Google this and get an authoritative data set: the number of factors involved are numerous, interrelated (one factor can affect another), and there is often no linear causal relationship between the factors and the outcome. It's a "Complex Problem" (also known as a "wicked problem").

Probability and cost/benefit analyses depend on a stable system. The problem with information security is that stable digital systems are unusual. Digital systems get more complex with every update, patches alter how systems function, the system context can change, people use and maintain the system, and the external threats to the system are sentient and adaptive. Each of those factors changes the underlying basis for a calculation.

There are ways to get closer to a probability calculation using formal probability approaches. And you will want to read How To Measure Anything in Cybersecurity Risk for that. But the author takes the approach that systems and their context do not change enough to worry about deviations. I debate that as a universal premise. It's true in some contexts, just not any that I have worked in.

If you constrain your analyses to the stable form of a system, then you can end up with a calculation for a system state and context that no longer exists. Fancy answers that are functionally useless as a decision support for what to do next.

To do the analysis that you want to do:

Analyse your systems in context to identify those factors that are linear with known and limited cause/effect contexts. What's linear for you might not be linear in another org (and what's linear for you might change over time). You then work out probabilities for those things.
Then you need to identify the non-linear contexts, the Complex contexts, and get as many people who know the systems and contexts together to get their opinions. For Complex contexts, you can't use linear calculations of probabilities: you need perspectives. Then you track those opinions over time.

There is a very real possibility that you will not be able to perform a cost/benefit forecast analysis, only a retrospective one. Knowing that is very important.

To learn more about this problem, look up:

Dr Nancy Leveson from MIT - she asserts there is a complexity threshold in social-technical systems where impact and likelihood is inherently unpredictable
Dr David Snowden - creator of the Cynefin Framework around making sense of contexts that are a mix of the linear and non-linear (and then what to do about it)
WEF's "Towards Quantification of Cyber Risk" - promoting the "Value-at-Risk" approach, which is a nice way of averaging out the historical data to make some useful inferences
I have also done work in this area for a few years. My first slide deck after I asked this same question six years ago.

The slide deck explains how several frameworks approach this problem:

COSO
ISO 31000/ ISO 27005
NIST 800-39
RISK IT
FAIR
OCTAVE Allegro

The US Government Accountability Office (GAO) has this to say about the problem:

  “Reliably assessing information security risks can be more difﬁcult
  than assessing other types of risks, because the data on the
  likelihood and costs associated with information security risk factors
  are often more limited and because risk factors are constantly
  changing.”

  “Even if precise information were available, it would soon be out of
  date due to fast-paced changes in technology and factors such as
  improvements in tools available to would-be intruders.”


Is it a bad idea to share the ssh host key in a diskless environment?

The private key is the distinctive power of each machine. Having distinct keys for the machine makes sense, from a security point of view, only if the machines are not equivalent to each other. As you note, if an attacker obtains full control of one machine, then it can spy on the network and observe the files of all other machines, including their SSH private keys. It could also simulate the bootup procedure of any other machine, using the MAC address for that machine at the BOOTP/DHCP/whatever stage, and obtain all the secret values of that other machine. In short words, hijacking one machine can easily be expanded into hijack of all the machines. In that context, per-machine private keys would not buy you anything more.

If you want better security, including some isolation layer which would make machines not equivalent to each other, then you will need some heavy artillery. NFS is built over RPC, and there is an extension called Secure RPC which allows for encryption of all the data; however, it is old, poorly supported (I am not sure Linux supports it, for instance), and poorly maintained (if at all). A newer and arguably better method would be IPsec. Alternatively, one can encapsulate the NFS traffic into SSH, as explained in section 6.4 of this document. This raises interesting chicken-and-egg questions: how do you setup some SSH (or IPsec) in order to tunnel NFS in it, if you already need the NFS to obtain the SSH (or IPsec) private key ?

This is a rather generic point. Diskless systems are diskless. As such, they are, when shut down, identical to each other. Since a diskless machine cannot permanently store anything, it cannot contain any secret value which would give it some power denied from other machines. Consequently, all the diskless systems can be "emulated" from other diskless systems, in the bootup procedure, as alluded to in the first paragraph. Therefore, you cannot really create a context where the diskless machines would be really distinct from each other; as a corollary, you don't need to make the SSH private keys distinct.

Some notes, though:

If you can arrange for each diskless machine to have some local storage, e.g. a SD card on which it boots up, then you can put machine-specific secret values in there; and then you can have per-machine SSH private keys. Simply, the private key is read from the SD card, not from NFS, and private keys cease to travel unprotected on the wire (they cease to travel at all, which is even better).
Theoretically, you can get replace such local storage with human storage: arrange it so that a trusted sysadmin presides at each bootup, and enters a long secret password in order to unlock the machine secrets. I am not aware of existing software which would allow that, but there is no conceptual limitation. Except, of course, the need for the physical presence of a sysadmin every time a machine must boot or reboot, which is likely to be an unbearable constraint.
Don't put too much trust in VLAN. There are several protocols for that (standard and proprietary), but most are unprotected: frames are tagged by switches so that they know whether a frame should be shown on a specific wire or not. If an attacker gets physical access to one of the switches, or to a wire connecting two switches together or one of the VLAN-able machines to a switch, then he will get full access to the VLAN contents.
These are students. Compromise of a machine at some point is a certainty. One of them will unplug a machine, plug his own laptop in its place, configure the laptop to assume the IP and MAC addresses of the unplugged machine, and read all the files. This is easily done, in less than a minute, with generic OS tools. This goes a long way to say that if the students are attackers, then you are doomed. You can try to deter them with physical shielding (don't leave wires accessible in any way) and threats (trespassers will be beheaded and their corpses put on display), but this won't ultimately work. A better method, that I saw employed with success, is empowerment: monitor things so that you identify students who seem to be interested in security, and give them official admin power. They will not hack into machines that they already have root access to; and you can make them co-responsible for security, so they will cooperate in tracking trespassers.
A very common method for security is not caring. Just let the diskless stations become a godless wilderness, and filter things at the periphery. Students are creative and prone to test security, but they also get bored pretty quickly. Whether that method is good is an open question, but at least it is very easy to implement.


It sounds like the only attack you're worried about is that someone might counterfeit one of the IOUs. Therefore, I need to pick something for my IOUs that is hard to counterfeit. This suggests that money is still a good model.

I could just say "I'll hire an engraver to engrave some very detailed and intricate plates, mint four certificates from those plates, and use those certificates." That's what actual nation-states do, when they want to create tokens that are exchangeable for goods and services — excuse me, "favors." Such tokens are non-counterfeitable because hiring an engraver is expensive — like, state-level expensive — and we're not worried about that level of adversary.

However, hiring an engraver would also be very expensive for me. That's not good. Is there some way for me to piggyback on someone else's expensive engraver?

Here's what I'd do. I go into my wallet and pull out four 20-dollar bills. (100s if you've got 'em. Fives are probably okay. Probably don't use singles.) I write down the serial numbers on a single piece of paper. I give this paper to my descendants. I give the 20-dollar bills to my creditors. I tell my descendants, "If anyone ever presents you with a 20-dollar bill with one of these serial numbers on it, you do what they say, okay?"

If my descendants are really paranoid, they take the presented 20-dollar bill to the bank and have a teller look at it, before they do what the guy says.

In fact, if I and/or my creditors are smart, we'll take the bills to the bank and have them examined (after I write down the serial numbers, but before I hand them out).

The above scheme is foolproof for as long as

20-dollar bills are legal tender, and
your descendants have access to a bank that accepts U.S. currency (which admittedly might be tricky if you are a family of pirates).

The Fed estimates that in circulation, any U.S. bill will last at least 4 years; and if you treat it like the average $100 bill and keep it "as a store of value," it'll last at least 15 years.

Observe that a U.S. bill shows its serial number twice — on the left and right sides. You might be tempted to rip your $20 in half, give half to your creditor and keep half for your descendant. The problem with this idea is that two-halves-of-a-ripped-$20 are not legal tender, and so you lose your safety net: if you suspect forgery, you can no longer ask a teller, because they might just say "Nah, we don't take ripped $20s," and refuse to speculate about whether both halves were originally real or what. So, don't rip that bill!


Get the privileges of root with the user with I do an exploit with Shellshock

You'll need to identify and exploit a privilege escalation vulnerability on the machine.


Is bugged CPU mean "gameover" for whole Computer?

Your question is not very clear.

If you mean that the main CPU includes some backdoor for eavesdropping, then in principle, all bets are lost. No matter what protections the operating system might include, the CPU could simply not execute them (but pretend to). In practice, if such a backdoor was identified, there might be a way to work around it, because the CPU is set in stone and cannot evolve whereas software can be designed with the CPU backdoor in mind.

If you mean that the processor of the Ethernet controller contains a spy, then the spy sees all incoming packets. It's no use dropping the packets in the OS since the Ethernet controller sees the packets before the main CPU — its job is to send them to the main CPU. The spy would not be able to decode encrypted communications since these are decrypted by the CPU.

However, malware in an Ethernet controller could do more interesting things than just listen to network traffic. The Ethernet controller generally has access to internal buses such as PCI which allows it to transfer data to and from memory, so on most architectures it could read the RAM of the computer.

There have been buggy Ethernet controllers in the wild. For example, there have been incorrect implementations of Wake-on-LAN. In this particular instance, a machine was vulnerable only when it was plugged into the network but turned off. An attacker would typically have needed to be on the local network since most firewalls filter these packets.


Who watches the watchmen? User empowerment over firewall behaviour on a personal computer

The built-in Windows firewall is now advanced enough that third-party firewalls typically don't have anything left that is useful and novel to bring to the table.

So security experts generally don't use third-party software-based firewalls. There's value in hardware firewalls, which offer a layer of protection against a compromised host, and there's a value in software firewalls, which offer a zero-cost baseline level of protection for all devices or a fall-back secondary layer of protection beyond just an external HW firewall. But really the one that comes with newer versions of Windows is more than sophisticated enough to fit that role. The additional security to be gained by installing a third-party alternative rounds to zero.

As for the general question of trust; that really is the kicker. I trust Microsoft to patch Windows because... I have to. Do I trust Adobe to update flash correctly? Oh, how about this: do I trust Oracle to ship spyware-free updates to Java? (Stupid Ask toolbar). But if I can't trust Oracle, then who can I trust to update Java. Or... do I just have to abandon Java altogether?

You don't so much watch the watchers so much as you pick the watchers when it comes to application security. Either you trust the vendor and install their software, including its updating and tracking behavior, what every that may be ... or you don't.


Is it possible to construct a passively self-destructing message?

Let's dispense with the "if it can be copied" part first. I can start with a camera and work my way down from there. I can also enlist a sufficient number of monks, nevermind digital media.

You're on a track with radioactive decay. If you can arrange a sufficiently large key that is represented by a number of decaying radioisotopes and arrange that key with a error correcting code, then you would have a predictable loss of the key within a certain time window that's a function of losing N bits of data at a rate determined by the half-life of the radioactive media combined with the M bits of losable key.

This still leaves the idea that a partially decayed key provides a better place to start than a fully decayed key, but then we're back to math about the number of attempts to fix the errored key and that's a mathematical combination as well. Once the key is decayed such that half the bits are likely wrong after the error correctable size then your data would be guarded just as well as if an attacker had nothing.

Doing the time-related math for your selected radioactive material and EC code is an exercise for the reader.


Security benefits to have IP-filter in HttpModule instead of Page-Load in asp.net pipeline?

From a security perspective, it's desirable to discard the unwanted traffic further up the chain and typically at the lowest level of the OSI model you can.

This is beneficial because it reduces unwanted noise, can save processing cycles on the equipment downstream, and makes the control less likely to be bypassed.

In regards to IIS specifically, the request filtering module (Where IP address restrictions are specified) is processed before all other modules.

Image from: http://www.iis.net/learn/extensions/url-rewrite-module/iis-request-filtering-and-url-rewriting

So the answer would be the above falls under best practice.

Is there a reason that you aren't taking advantage of the native IIS IP address filtering capabilities?

Please reference: Configure IPv4 Address and Domain Name Deny Rules (IIS7)


So I wonder, is it even possible to have a hash function that is secure, irrespective of the time it takes to execute?

No, of course not. Think of a hash function as something that takes in any string and outputs a short fingerprint of that string. If I have a computer fast enough to list all possible strings and compute their fingerprints (aka hash values), then I can build a lookup table mapping every hash value back to the string that produces it. With an infinitely fast computer with infinitely large memory I can build a lookup table which breaks any hash function, even theoretical ones. Period.

For a real hash function like SHA2 which has a 256-bit output, assume you were magically handed that lookup table for all 2256 possible outputs, and assume it takes you 25 ms to perform each hash, it would take you 6.7x1057 x age of the universe just to verify that the lookup table is correct. Now, if instead of being handed the lookup table, you had to compute it yourself through trial-and-error, that number would be even bigger. So yes, all hash functions can be broken by a "really fast computer", but like really really really fast, like ages of the universe faster than any computer that we have today. [As pointed out by @BlueRaja-DannyPflughoeft in comments, getting enough electricity to do this computation would require consuming several stars so it's not physically possible for a pre-interstellar society]

The reason that attacks are tractable on modern hash functions, which forces us to do tricks like salt&iterate to make them slower, is that for things like passwords you don't need to check all 2256 possible pre-images. If everybody used random password generators then this would be true, but people don't ... in fact 1.5% of us (1 out of every 68 people) use the password "123456" (source). So you only need to check things that people commonly use as passwords. A list of the 100k most common passwords will get you almost all the users on the internet, which a modest computer can check in a few minutes if they are only hashed once. We compensate for people's weak passwords by making each hash computation take longer. If they are salted&hashed 10,000 times then that few minutes on modest hardware goes up to months on a custom GPU rig.

In summary; a lot of the problems we have with hashes aren't because the hashes themselves are weak, but because we're asking them to protect data which is easy to guess.