Java UUID.randomUUID() or SecureRandom for id segment on URL?

In terms of the raw amount of random bits, yes.

Looking at the source for Java's random UUID generation, you can see they actually utilize the SecureRandom class to generate the raw bytes.  So, the 'quality' of your randomness isn't going to change.

The fact that you have 6 more bits does, technically, make it more difficult to brute force a duplicate.  Wikipedia's article on UUID has a good description of the math behind it.  To quote it:

  [A]fter generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%

If these links are going to expire in, say, 24 hours, this is a very small thing to worry about, and that's only with 122 bits.

Now, is more bits going to make it harder for an attacker to brute force a collision?  Sure!  Is it worth it?  Maybe... but maybe not.  Only you can really decide what's right for your use case.

When you get to the point where brute forcing a collision would, on average, take longer than the time for the estimated heat death of the universe, it might be a little overboard.  That's getting to the territory of needing to worry more about hackers compromising the security of your storage more than brute forcing (and, honestly, even with UUIDs, you're going to have that problem).  Ultimately, the difficulty of brute forcing doesn't matter if they can find another way in.  If you're really worried, storage is cheap - store 256 bit strings that you generate with a SecureRandom and call it good, but make sure you have proper security around everything else, or it's useless.


First, there's a terminology issue when talking about this stuff. Strictly, 'BIOS' and 'UEFI' are different programming interfaces for the firmware present on PC motherboards. However, in a PC context, 'BIOS' is often used to refer to the firmware irrespective of its API -- that is, "UEFI BIOSes" should strictly read "UEFI firmwares".

(Just to be clear: that's not me picking on your choice of words. This ambiguity is rampant throughout discussions on this subject.)

However, realistically, what @andré-daniel said is right: a lot of PC firmwares are vulnerable to these kinds of attacks, because they're not particularly well-hardened. UEFI just makes it easier to attack in an automated fashion because there's a lot more code sharing and reuse between UEFI firmwares from different motherboard manufacturers than there was between BIOS firmwares.

Remember, though, that firmware attacks require code running on the machine, and it needs to be able to get into kernel mode. So preventing malware from running on your computers in the first place is of paramount importance. Safe browsing habits, anti-viruses, and up-to-date software (especially the OS kernel) will all help.

So, in short, yes, you probably are vulnerable to these attacks. Yes, flashing a more recent firmware is likely to help. But you're dependent on the motherboard manufacturer to release updates, which manufacturers are terrible at doing. So there's actually scarily little anyone else can do, apart from try to prevent malware from running.


How to Check Compilation Options For SO File - Android Application VA

To determine if stack-smashing detection has been compiled into the binary, after decompilation with apktool, your shared object libraries as you know can be located in <apktool_outdir>/lib/<arch>

cd <lib_dir>

for o in $(ls); do echo -e "\n\n$o:" && strings $o | grep stack_chk; done


Using buffer overflow on word with macro injection

Why would you bother using a bufferoverflow when using Macros? It would be easier to just inject some VB script which does calls to, for instance, powershell (there is a really good exploitation framework here named PowerSploit).

Exploits which do target bufferoverflows within Word, are a lot harder to find and exploit. If the target has EMET installed, you're immediately completely out of luck.


Sharing Wi-Fi with rental dorm using different frequenzy bands?

With out any more details I would say yes, this is a bad idea.

2.4ghz and 5ghz are not isolated even if you give them both separate SSIDs they will still connect to the same network, both 2.4 and 5 traffic will use the same network.

you would basically just deciding who gets the faster wireless speed.


How can the Magic SysRq key be dangerous for linux users?

It can be used to display CPU registers (which could contain bits of confidential information), forcibly unmount filesystems or reboot the computer, among other things (denial of service vulnerability).

I wouldn't say it is dangerous though. If you have physical access to the server there so much you can do without even using the "magic" key. A lot of distributions for example allow rebooting the server with Ctrl+Alt+Del without being logged in, but even if that's disabled, just unplug the power cable.

Once an attacker has physical access, all bets are off.


You can setup bitlocker (with SED) without TPM. But...
if you dont want to use USB and if you dont want to enter preboot password then TPM is required. TPM is required to save keys that require for SED to unlock. SED must be OPAL complied to work with TPM.


Thought process on Network Protocol Attack

The protocol does not mention any random padding, which means that E(P,m) is a deterministic function. It means that, given the same public key P and message m, the result of E(P,m) is always identical.

If the attacker C can sniff E(PA, m) and E(PB, m), then they can try all possible values for m, and see which m results in the same encrypted message.

The viability of this depends on the entropy of m. If the contents of m can be reasonably guessed, then this is a viable attack. If m has high entropy (e.g. a randomly generated encryption key), then this attack is not viable. In that case, I wouldn't know how C would be able to recover the message, though I would love to know.

Question (b) is asking how this attack can be prevented. The simple answer is by including a random padding, which is distinguishable from the actual message.

So by modifying the encryption algorithm to be like E(P, m||pad), with pad being chosen randomly, the encryption function can't be exploited in the same way anymore. The attacker C doesn't know the padding, so even if C would happen to have the correct m and calculate E(PA,m), the result would not be identical, as C does not know the padding being used.

In regards to the padding: The padding requires two things:

The padding must be sufficiently long and random so that is infeasible for the attacker to try every message with every possible padding. What this actually accomplishes is to guarantee that every message sent has high entropy.
The padding and the message must be sufficiently distinguishable. This can be accomplished by making the padding a fixed length. The recipient would know that the padding is this length (e.g. 256 bit) and can remove the last 256 bit, and before sending a new message, create a random 256 bit padding.


From OWASP:

  In order to minimize the time period an attacker can launch attacks
  over active sessions and hijack them, it is mandatory to set
  expiration timeouts for every session, establishing the amount of time
  a session will remain active. Insufficient session expiration by the
  web application increases the exposure of other session-based attacks,
  as for the attacker to be able to reuse a valid session ID and hijack
  the associated session, it must still be active.

It all depends on the risk appetite of the organization. Each organization will do a risk assessment and decide what type of data they are protecting and what their customers find acceptable in terms of usability. For instance, Gmail may not expire their sessions because it is deemed that the benefit of users not having to log in each time generates more revenue than the reputational losses they have when a Gmail accounts is hacked due to non-expired cookies. Of course the content of an email inbox might be sensitive or it might not be, it's debatable.

Bank applications on the other hand are in 99% of the cases containing money. Furthermore the reputational outfall of "bank X customer gets hacked" generates a lot more unrest than the Gmail example. Customers will start calling the bank worried, they might loose clients who believe their system is unsafe etc...

In the end it's just looking at your threats and vulnerabilities and assessing what the cost and benefit is of implementing mitigating controls (which in this case is the expiration date of a session).


Sending non-expiring access token on each request vs using refresh tokens?

When working - for example - with JWT tokens, the tokens are self-signed.
Which means that the resource service can verify the token's integrity without having to communicate with the authentication server. Which is fine to do with short-lived access tokens.
But when the refresh token will be used to acquire a new access token from the authentication server, the authentication server could be performing more validation like checking if the session was revoked or if the user's account still exist, is still active and still has the rights to access the resource service for which it will issue a new access token.

In that case, using refresh and access tokens can help you implement simpler validation mechanisms for short-lived access tokens, allowing faster response from your resource server.


Security announcement mailing list for Java

You can subscribe to Oracle's security advisory mailing list by following the instructions at http://www.oracle.com/technetwork/topics/security/securityemail-090378.html.

You should also read http://www.oracle.com/technetwork/topics/security/alerts-086861.html for more information. In particular, the section relating to third party bulletins.


Take a look here: Scan for POODLE using nmap from a Windows machine

nmap.exe -p 443 --script ssl-enum-ciphers -oN poodle_443 facebook.com


Is it ok to let someone unlock their own account with their admin account?

Let's examine why this person has multiple accounts - the general explanation is that there should be an additional barrier to access administrative functions, reduce logins to that account, etc (https://cloud.google.com/resource-manager/docs/super-admin-best-practices). You can consider their admin account their 'primary' account (even though it's not the one they use day-to-day) as it's what matches their role. Nothing else they can do on their admin account has to be done by someone else.

Resetting your own password via your admin account isn't poor practice. Getting locked out of an account that should be your day-to-day account is a potential yellow flag. There are no separation of duties between these accounts - this person is presumably allowed to perform the actions in their admin account. There is also no privilege escalation - the lower level account is a best practice, and not a reflection of the user's permission level.


The first bit of code shows a spam link and then some JS to conceal it, so it will give the spam site a SEO boost while remaining invisible to the admin (as far as I know search engines still don't interpret JS, so to their eyes this link is always visible).

The second link completely redirects the user to a spam website in the event that they are coming from a search engine, based on their referer. An user reaching the page directly (like the admin) will not get redirected and won't notice this. They seem to be targeting the Japanese versions of those search engines which gives a clue as to where the malware originated from (or who paid for those spam links to be placed there).

I would bet good money they are using an awful CMS and got compromised. Simple as that.


How would I turn an open telnet shell into a Metasploit session?

If you have root on the server (or any kind of shell access), generate a payload on Metasploit, copy it to the server, and execute.

You don't turn telnet into meterpreter, you start another connection.


Does flooding with bytes cause buffer overflow?

Flooding bytes is one thing but how are you going to do it? There are many takes on this.

There are generally two types of buffer overflows, through the stack or through the heap. The most common one of all would be through the stack which can be illustrated in the answer of this post and in this site (using c) both using c to illustrate.

This site also does a really good job of illustrating and breaking down the flow of the exploit, also using c.

It talks about the,

Memory Layout of a C program and how it runs, (if you can grasp this concept well, half the battle would be already won)
Common & Key registers
Memory Management during function calls
How the vulnerability is exploited on the low-level codes of C/C++ (which c functions are vulnerable to the exploit)
Designing respective payloads


Patterns in password creation over multiple passwords

It depends on what kind of attack you are trying to protect against:

If your password is one among millions in a data breach where the attacker isn't targeting you specifically, then your password is effectively 10 random characters long instead of 8. It will be harder to crack.
If an attacker is targeting you, and knows about your pattern, then it gives you no protection at all.
If an attacker is targeting you, and doesn't know about the pattern, it could help until the attacker finds out about it. Breaking one account would give a little help, breaking two would make the pattern obvious and hence useless.

So your system could be helpful sometimes, but not always. Or in other words: your "effective" password length will be somewhere between 8 and 10 depending on your threat model. But unless you have some specific reason not to, I would just forget all about clever systems and just install a password manager instead.


Elliptic curve cryptography and key sharing

With asymmetric cryptography, you normally encrypt with the public key, not the private key; with the private key, you decrypt. Moreover, asymmetric encryption is usually randomized, so it can be hard to tell that you get "the same result" than what you would have with a single private key, since you can actually get a whole range of values (which would decrypt to the same message, though). Maybe you want to speak about signatures ?

In any case, there are a lot of possible protocols for multiparty computations (that's the term for that kind of things). See this site for a lot of links. In your case, I suppose that you have two parties who need to use a private key so that their combined actions are equivalent in some sense to what could be achieved with a single secret value, that neither knows. Protocols which achieve that depend on the exact extent of the knowledge and action of both parties:

Are the two key holders considered to be potential active attackers, or only passive ? I.e. do we want to protect the secrecy of the scheme if one of the parties begins to send incorrect, carefully crafted messages to the other ?
What is the level of control that the key holders have on the input data ? Can they modify it in some way to reveal information about the the other key half ?
Should each party be able to ascertain that the other party played the protocol faithfully ?
Should such a proof be discloseable to a third-party without revealing anything about the processed data or the keys ? (This is the kind of proof that is very important in, for instance, e-voting protocols.)
What can the key holders be allowed to do ? E.g., if they can encrypt, is it OK if they can also decrypt (assuming they collaborate to the task) ?

As an illustrative example, suppose that you have an elliptic curve E with prime order n. Parties A and B knows secret keys a and b respectively; both keys are chosen uniformly in the 1..n-1 range. Suppose that you can map some input message m into a curve point M. Then A may "encrypt" the message by multiplying M with a; similarly, B multiplies points by b. If both A and B process the message in due order:

A receives M and outputs aM.
B receives aM and outputs (ba)M.

The final result is then equal to (ab)M, the result of the "encryption" of M by the key ab (product is modulo n), that neither A or B knows. It can be shown that A cannot learn ab regardless of what he sends to B; and the same applies to B if B is the villain. Of course, if A and B reveal their private keys to each other, then they can compute ab.

(This is an elliptic curve variant of the Pohlig-Hellman cipher -- not to be confused with the other Pohlig-Hellman algorithm. It is also known as SRA.)


SECURECOMM 2011 will be in London in September 2011.


First, you must understand what /var is. It's not a different kind of file system, but a location in the Filesystem Hierarchy Standard (FHS) for storing...

  Variable files—files whose content is expected to continually change
  during normal operation of the system—such as logs, spool files, and
  temporary e-mail files.

/var
    |- log/ - System log files
    |- mail ->spool/mail/
    |- run/
    +- spool/ - for programs in which data files are stored
        |- at/
        |- cron/
        |- mail/
    |- tmp/

There's no limitations preventing an antivirus from scanning in /var, but it would not be wise to scan log files etc. On the other hand there might be several locations that could be meaningful to scan, e.g.

If the mail spool is Maildir based, it's possible to scan mail for viruses on filesystem level and take immediate action. On the other hand removing viruses from mbox based system might break something.
If there are public web sites stored in /var/www, scanning that location might prevent a web server from distributing malware.


If there's a strict policy of not letting anyone from outside the company to use the company WiFi, and if it's monitored, the logs may reveal that there was an unknown computer logged in using your friends credentials. The worst that could happen is that your friend will get some company policy based consequences, even get fired, but that's not in a scope of technological information security.

Usually the collected information could contain your MAC address, operating system type, hostname and of course it's possible to log any data transmitted during the connection. That could be used to identify you, for example if your hostname has your name in it (MBP-agr96) or if the MAC address can be otherwise be connected to you.

The MAC address could be compared afterwards even if you

delete all the traces of the connection from your clients settings as suggested
delete all the related client side logs
overwrite your entire hard drive.

The connection alone doesn't leave any tracking capabilities to your computer, but theoretically the same machine could be identified based on the the MAC address whenever you connect to a WiFi AP the same administrators have access to. In reality... ain't nobody got time for that.

Personally I'd protect company networks not only from unauthorized friends but from any unauthorized BYOD devices, too; either by using RADIUS for machine authentication instead of user authentication or by bocking any unknown MAC addresses i.e. with a MAC address whitelist.


What are the differences between MD5, SHA  and RSA?

It's not the type of output.  Hex is just the way the data is formatted - since all of them are working on binary data, hex makes a great deal of sense.

The important part is what they do and how they do it:

MD5 and SHA are hash functions (SHA is actually a family of hash functions) - they take a piece of data, compact it and create a suitably unique output that is very hard to emulate with a different piece of data.  They don't encrypt anything - you can't take MD5 or SHA output and "unhash" it to get back to your starting point.  The difference between the two lies in what algorithm they use to create the hash. Also note that MD5 is now broken as a way was discovered to easily generate collisions and should not be used nor trusted anymore.
RSA is an assymetric encryption algorithm.  You have two keys (private and public) and you can perform a function with one key (encrypt or decrypt) and reverse with the other key.  Which key you use depends on whether you are trying to do a digital signature or an encryption.


Adding 65K buffer to protect from buffer overflows?

No. Most likely, you got that 64k limit from the Heartbleed bug, hovewer it is purely because in HTTPS Heartbeats the length field was 16 bits long. It doesn't mean that in your case your software will not have a buffer overflow reaching far further. So while yeah, this could add a tiny bit of security, you must always assume that buffer overflows can affect your whole address space, both after the buffer and even before it.


There's nothing inherently wrong with using what you've described.  With certificate pinning, and strong user authentication you're going to be on par with most normal TLS web traffic.

Ensure that you're restricting communication in your certificates to only secure ciphers, setting a reasonable expiration date, and distributing the certificates in a secure out of band manner (don't just email the certs to the device).

Lastly the one pitfall I could see is the manner in which you do certificate pinning.  There's two approaches to 'certificate pinning'.  You could pin the entire certificate, and fail the connectin if that differes, or you could check that the keys used in the certificate stay the same.

While it will take more effort to check the keys, I suggest you go that route.  It allows you to update the certificate server side, and have the client still accept it assuming your key doesn't change.  This provides the security of expiring certificates whenever you want, but still maintaining pinning.

I would caution you about using AWS for sensitive data.  While your data isn't subject to regulatory restrictions, you still should consider the location of your data, what laws it could be subject to.  How well does Amazon AWS scub their drives after use?  What SLA does AWS provide?  I haven't used AWS personally, I'm just echoing what I've heard from others at this point.


Zeus v3 - can I detect its existence "manually"?

I experienced this exact problem and my Sophos firewall also indicated the same warning two times in close succession. After that, there has been no further warning.
Two additional observations here that really confuse me:
1). The laptop in question is a macbook running macOS 10.14.3, and
2). The laptop was not running at the time reported in the logs.

The firewall is Linux-based and my only Windows machine is on a separate subnet.
All our other devices are wireless running ios 12.2

I can only explain that as a false positive.

One small correction: My laptop was closed but apparently was still pinging the network, according to the logs.

CRIT-861: MALWARE-CNC Win.Trojan.Zeus v3 DGA DNS query detected


CSRF Login: can Attacker Login using valid credentials?

Yes, it's possible.  Or rather, it would be possible, except that Google has deployed countermeasures to defend against precisely this attack.

This attack is known as "login CSRF".  It's similar to a standard CSRF attack, but a little different.  If you search on "login CSRF", you will find information on the attack.  It is a real threat against some web services.  For more details, see my answer to a related question, and the following research paper:

Robust Defenses for Cross-Site Request Forgery.  Adam Barth, Collin Jackson, and John C. Mitchell.  CCS 2008.

See especially Sections 1-3 of that research paper for more technical details.  The paper describes how to defend against the attack.

The short version of how to defend against the attack is that you include a secret CSRF token in all POST requests, including login attempts; and on the server side, you require that login attempts have the proper secret CSRF token included.  OWASP has more on how to deploy secret CSRF tokens.


What are the technical reasons for Tails requiring 2 USB sticks to install?

The primary benefit of the two USB drives setup is that it provides a secure environment (the first Tails USB instance) to generate the encryption key for persistent storage: a non-Tails OS could unintentionally leak the encryption key, thus causing the persistent storage encryption to be comprised.

If you don't require encrypted persistent storage, then the first Tails USB drive should be acceptable as-is.

The tails-installer-launcher application available on several Linux distributions such as Debian does not require a second USB because it creates two partitions on the single USB drive: the first partition is used to house the Tails OS, while the second partition is used to house the persistent storage. The installer application only installs the Tails OS to the first partition, so the encrypted persistent storage is still only setup through the secure environment of Tails after you boot into it.

Theoretically, you do not require two USB drives to install the Tails OS with encrypted persistent storage -- even without the tails-installer-launcher application. You can perform the operation of the installer manually by simply partitioning your single USB drive into 2 partitions, installing Tails OS to the first partition, then later setting up the encrypted persistent storage from within Tails OS to the second partition.

See also

  Can I Use Tails in One Stick of USB? ( 8Gb) instead of 2 (4Gb) Stick


First of all, the AES symmetric encryption algorithm (which ConverTo-SecureString seems to be using) is definitely not "one-way". You can always recover the plain password if you have the key, otherwise even the suggested sample wouldn't work.

The source of your problem seems to be that this sample code looks like a serious misuse of the PS/.NET API. The purpose of SecureString objects is to make in-memory attacks more difficult by hiding/deleting sensitive information if it's not in use. To achieve this SecureStrings may use encryption, but this is an implementation detail, not a service meant for this kind of "public" use. The sample may work nonetheless, you should note that (counterintuitively) encryption is done via the ConvertFrom- cmdlet, while decryption is done with ConvertTo-.

If you want a proper API for encrpytion start here.


Linking to a bank account: login credentials vs. routing information

I'm not a financial person and have wondered this as well. So, I think the best way to answer this question is by starting with which services a bank can provide and then what information is required to use those services. I investigated this by actually using the below services. There are two services that I know of to transfer money:

ACH: Your bank will require you to validate the foreign institution transaction before you can send money. There are also daily limits. This is largely the one security barrier between your account being drained by ACH.
Wire: Your bank sends your funds to wherever you tell them to (details below). There are no limits on this transfer and the bank will most likely assume zero responsibility in the event of loss of funds (at least mine did). The institution also does not verify the endpoint like they would with ACH; if you or the financial advisor fat finger the routing number or account number you are potentially at a loss. I asked both institutions before sending a wire transfer what happens if I miss a number and they both advised me not to do that and to triple check the numbers.

Both ACH and Wire require the same numbers to transfer: Routing number and account number (they did in my case, maybe not your institution, again you have to check). Wire transfers almost can never be reversed (I cannot back this up; but it seems like its in every liability). ACH however seems to have that capability. ACH again has limits; one institution I knew of it was $3,000 a day. This makes it next to impossible to drain your account via ACH, and since most ACH can be reversed it makes it less worth while to even try. Its also worth mentioning that ACH are limited to within the USA only. The only way to drain your funds to a foreign institution would be via an international wire transfer which has even more strict policies/regulations than a domestic wire. Also worth mentioning is that you usually need to know the account details of the foreign account to conduct the wire (such as the full name and address of the account holder).

So, with that being said. If you give your password to your bank account whomever it is will have access to your account numbers. This means they could setup an ACH transfer and disable any alerts you have and then setup a recurring ACH transfer that you may never notice. Doing a wire transfer is harder; most if not all banks require you to be physically present to conduct a wire transfer. Some do not; some allow you to fax in forms and your ID... So, let that sink in.

Another perspective for you is if you don't give them any information except your banks routing number and account number. They can then use ACH to request and take funds from your account (think eCheck or reverse Direct Deposit).

With that being said, you should never give your bank password or account numbers out. I find it disturbing that people will give these numbers out willy-nilly for gym membership (yes I'm pointing at you Planet Fitness!).

I should also mention that the routing number for the bank/institution is public information. You can often see it on the front page of the website; this means its one less number sequence for an attacker to find. The number the attacker wants is your bank account number.

You should read over the Security section for wires. Also worth mentioning is that the USA uses SWIFT to conduct wire transfers; this seems to be the target for malware and other types of attacks.


Two main competing DRMs are PlayReady (Microsoft) and Widevine (Google), but you won't find any specification. What you can do, just to start understand how it works. Read HDCP2 specification, it's open to public. It's not DRM, but content protection. Then you'll get some ideas. Also read https://w3c.github.io/encrypted-media/ see a block diagram. It's not DRM, but explains how DRMs are used with a common framework.


Concept needed: user specific encryption on server

Requirements 1.1 and 1.3 are incompatible; there's nothing that software can do which an admin of that software cannot do.

If you don't need the server to be able to decrypt the data at all, that works fine and is called end-to-end encryption (E2E) and is used for a wide variety of very secure tools. With E2E, only the client can decrypt the data; the server can only receive, store, and transmit encrypted blobs with no access to their contents.

Requirement 1.2 can be met by having the server store a public key for each user, and - when it wants to encrypt data to that particular user - first creating a new symmetric key, encrypting data with that key, and then encrypting ("wrapping") the symmetric key with the user's public key and storing the encrypted data and wrapped symmetric key together. The user, which is the only entity with access to the corresponding private key, is the only entity that can unwrap the symmetric key. However, this still requires that the server be trusted, or else it (or a malicious admin) might do something like also wrap the symmetric key with their own public key, or just store the symmetric key (or the data itself) in plain text somewhere.

Requirement 2.1 is fundamentally impossible if there is no fully-trusted agent to do the decryption for you. If the server is doing the decryption itself (and is not fully trusted, because the admin isn't fully trusted) then the server/admin can steal the decryption key and hold onto it for later use. You can mark a key as "don't use after this date" but there's no (known) way to mathematically enforce such an inherently non-mathematical concept and cryptography is just math. Enforcement is up to the agent doing the decryption, and the key expiry is nothing but a suggestion.

Requirement 2.2 can be achieved by transmitting the key over a local network or Bluetooth, or encoding it as a QR code and displaying it on the screen, or other such methods. For maximum security, though, the key should be encrypted using a user-supplied password and decrypted on the other end, or better yet transmitted over an encrypted channel using an ephemeral key with the passwords used only to verify the ephemeral key parameters (this is known as "forward secrecy" and prevents an attacker from decrypting the key even if they recorded all the network traffic and later learn the password that was used).

Given the questions that you are asking, you almost certainly do not have enough security knowledge to design this system securely, or securely implement even a secure design. Designing new cryptosystems is hard, as is implementing them. For example, the SSL/TLS protocol is decades old, designed by people who theoretically know what they're doing, and has been through 6 different published versions because people keep finding weaknesses in the old ones... and that's just the design; the actual implementations in libraries like OpenSSL have had numerous and occasionally massive vulnerabilities.

If you have a specific use case in mind, there may exist well-reviewed software that already provides it (for example, nobody should be attempting to roll their own password manager unless they fully understand how the existing ones work and have some specific improvement they want to make but can't just get LastPass/1Password/etc. to implement it). Don't re-invent the wheel if you don't have to, especially if you're not quite sure how wheels work and want them to do several incompatible things.

If you're trying to create something that's totally new, document it and put out the document in a Request For Comments (RFC) so the industry can try to poke holes in the idea, and then after the design is done, open-source the code you write so that the industry can review your implementation. If the design and/or code must remain proprietary, you're probably not going to be able to achieve as good of security but you should still hire a cryptographic security expert (perhaps as a consultant) to review the design and implementation.


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

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

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


Will a `dd` clone between two drives effectively "wipe" the contents of the target drive?

That depends on what you mean by "sufficiently".

For magnetic disks, yes, overwriting the data like this should erase it sufficiently, and dd will write every block on the target drive. The idea that magic spy forensics can recover data from a magnetic hard drive that hasn't been overwritten some huge number of times is a myth derived from this paper by Peter Gutmann (see the several epilogues he's since added at the end).

Nothing about this applies if the target drive is flash storage, like an SSD. SSD drives have different data remanance properties. This paper suggests overwriting the entire storage container twice to guarantee that every block has been re-used. Properly implemented OSes can also inform the drive to wipe particular blocks via the TRIM, but the drive isn't guaranteed to act on these commands in any particular amount of time.


What is the simplest way to send an anonymous email?

Download Tor Browser
Using Tor Browser, go to a site like Send Anonymous Email


Issue regarding installation of SHA256 scertificate

Key Usage error

The key usage field shows exclamation mark because this field is marked as critical. This is not an error.

  why is it showing "Thumbprint alogrithm as "sha1"

Beacuse the certificate thumbprint (the field below it) is created using SHA1.


How to use public key in ~/.ssh for asymmetrical encryption with OpenSSL

That RSA key is for authentication, not for encryption!  You should not use authentication key pairs for encryption (if you literally mean extracting the ssh key to store encrypted data, rather than to share the keypair with an X509 certificate); because the public and private operations or RSA commute.  For example, if you use the same key for both:

encrypt = verify = public
decrypt = sign = private
public * private = private * public = 1

This sequence involving Alices signing and encryption key pair:

Bob to Alice:  "here is a secret message": secretMsg := message * public
Eve to Alice: "please sign this for me": secretMsg
Alice to Eve: "okey dokey": toEve: signed := secretMsg * private
Eve:

signed
secretMsg * private
(message * public) * private
message * (public * private)
message * 1
message

Eve got the plaintext of a message that was sent encrypted to Alice.  It is not exactly this simple because of formats; but it is well known that keypairs are either for signing/identity or for encryption, but should not be used for both uses.


Plausible deniability is really more of a political or social tactic than a security measure. As a tactic, plausible deniabilty seeks to prevent the disclosure of information by presenting an argument about the knowledge a given individual has. This is a second order game, at least one level removed from direct protection of information.

An Example: Alice is a ruthless criminal. Bob and Don are her criminal associates. On Monday Bob is a witness to one of Alice's crimes. On Tuesday Alice and Bob have an argument. On Wednesday Bob meets with Carol and tells Carol some confidential information about Alice's activity on Monday that could be used to arrest and prosecute Alice for her crimes. On Thursday, the next time Bob and Alice meet, Alice asks Bob who he met with on Wednesday. Bob claims he met with Don, another of Alice's associates.

By naming Don instead of Carol, Bob has provided Carol plausible deniability about the information he provided to her.

If at this point Alice decided to kill anyone with information about her criminal activity on Monday, she might decided to kill Bob and Don.

How is this relevant to Truecrypt?

Truecrypt is trying to play a similar game. Rather than try to disguise the fact that a user has encrypted some information. They are giving the user two shells under which to hide information. Under shell A is confidential information the user wishes to keep private. Under shell B is information the user is willing to disclose if that disclosure keeps the information under shell A confidential.

Now the content of the information under shell B ("the decoy") is important. If nothing is kept there except freely available public domain information. The plausible deniability will not work. It will not convince anyone (law enforcement, border patrol, or spouse) that the user went to some effort to protect the information. And since the fact that Truecrypt offers 'Plausible deniability' as a feature is well known, most professional phone inspectors will know that what you have presented is a 'decoy'.

Further notice that this tactic depends entirely on the inspector deciding that it is not plausible you have the information they are seeking and as a consequence do not pursue them further.

Lets go back to the criminal Alice from the first example. Lets say she decides not to believe Bob about who Bob met with on Wednesday. Suppose that Alice knows that Bob is friends with Carol and decided to kill Carol just in case Bob told Carol the incriminating information. At this point the plausible deniability tactic's value goes to zero as the recipient of the tactic uses possible instead of plausible as the discriminator for the decision to take action.

That means that this tactic only works against those whose decisions for action are evaluated based on plausible evidence. And most persons who are not under the instruction of a magistrate have a much lower threshold for suspecting guilt.


Unclear attack(?) on web server: GET requests for tar files

I doubt this is a targeted attack, similar to what most people said in the comments, this is a bot probing for tarballs created by a naive webmaster or archiving software. Don't pay these bots much attention as they likely scan the entire IPv4 space.
If you are still unsure if the attack was targeted, you can use IP reputation tools like Greynoise and AbuseIPDB to determine if the attack has been seen by others.


How to use TPM to identify a computer for licensing purposes?

As you are going to run a open source OS, attestation will not work as reliably. The TPM will be able to attestate up to the loader of the OS, but after that, attestation becomes difficult as open source software is easy to modify.

I would suggest using the attestation identity key, to create a remote attestation signature (TPM_Quote) and then use a cloud service to host most parts of your application.

The client app just acts as a "dumb interface" to the cloud server, and the TPM_Quote is sent to the server as a "login". This can also be used to negotiate a "session key" that only the TPM and your server, can use to encrypt/decrypt.

This means that a cracker can copy your application until the cows come home, it wont matter, as your server will not accept a TPM_Quote from a tampered system.

This also makes it easy to revoke licenses if they are misused, for example if a customer is for example abusing a personal license by lending out RDP/VNC access to the computer to individuals outside of the customers premises.

Note that unencrypted application still needs to be available to the host OS, so regardless of which TPM features you use, it will still be crackable as long as the verification is done locally. Even if you use attestation with sealed storage and curtained memory, a cracker will still be able to crack the application, as sealed storage and curtained memory can only contain data, not executeable code. (yes, you can have executeable code in for example curtained memory, but for the host OS to be able to execute it, you need to move it outside of curtained memory).

Thats why you need to use a cloud service, so you can enforce the non-tampered state of the client computer from a central location that a cracker cannot physically access, and then host the application on this location, so even if the cracker has complete access to the client-side source code, they cannot take advantage of the service in question.


XSS - Can we steal cookies from another website on another tab?

Depends on how well the browser has implemented tab separation and cross-site origin policy. In modern browsers, no, you won't be able to do that. It would be possible to write a non-standard conforming browser that would allow you to access third party cookies, but at that point, the attacker can do much more interesting things, so being able to steal cookies is pointless.

In old browsers (very old browsers - I'm talking pre-IE4 era, if not even earlier), it's possible various tricks would get the browser to send the wrong cookies, but these are relatively easy bugs to pick up with automated testing, so they should have been fixed a long time ago.

The responsible thing to do in this circumstance is to let the ecommerce provider know about the XSS issue, providing all the details they need to recreate it, so they can fix it. They might even give you a reward, depending on their policy. However, it is usually illegal to go looking for issues without permission from the site owner - if they have a bug bounty programme, they will usually mention it somewhere, along with restrictions on the kinds of investigation they allow.


Hidden TrueCrypt Container containing the Tor Browser Bundle

It's unlikely that Tor browser will leave any trace outside of the Tor browser folder.= unless you tampered the configurations. Even if you switch downloads to a folder outside of it, it will still download within it's own folder.


Will my USB modem send my MAC address to my ISP?

Your computer doesn't have a MAC address on its own, a MAC address is something related to the network adapter. So your USB Modem (I'm assuming you're talking about those 3G/4G USB Modems) has its own IMEI (or MAC address in some cases), and when you use it to connect to the Internet your ISP will see it.

If your ISP doesn't require you to install an application† to use for the connection, then I don't see how they can find out that you're using the same USB Modem on two different computers.

† Such application might gather some data about your computer and come up with a sort-of identifying signature comprised of information about OS installation and/or hardware.


You make the assumption that by using public WiFi your phone can be hacked.
This is false.
Connecting to a public WiFi does not allow someone else to install an application on your phone. It does not allow someone else to "hack" it either. Hacking is not a magic button someone has to push and wait for the magic to happen. Real life is not a movie.
(For the cyber-nerds out there: this answer is an attempt at vulgarization. Some simplifications were voluntarily made.)


"Cyber" is a very frequently misused buzzword people like to throw around because it sounds futuristic and cool. What many people mean when they use the word is "computer-related".

What it actually means is the short form of Cybernetic: The integration of human and technology.

What the quote could mean (you are not providing context) is that machine learning can help for security problems in machine-machine interaction (digital) but not human-machine interaction (cybernetic). For example, you can already use machine learning to teach a program to automatically detect an automated brute force attack on a login form, but you can't yet teach it to automatically detect a phishing attempt. (I am not claiming this is right or wrong, just that it might be what the author wants to say)


OpenPGP: Sign-Verify workflow without Encrypt-Decrypt?

Such a signature is good for two things:

It protects the email against alteration (i.e. any modification will be, at least, reported as such by the recipient's software).
It gives to the recipient a proof that you the message is really from you; that proof can be shown to a third party (that's a signature, not a mere integrity check).

In email context, we usually encrypt when we sign, because if there is an attacker who is willing to modify the email contents, he is probably interested in reading the email as well, and you probably want to prevent that, too. A signed-but-not-encrypted email is still a rather common occurrence, for the side effect of making the recipient aware that you are using OpenPGP; some people systematically sign all the emails they send, even those that they cannot encrypt because the recipient owns no key whatsoever.

In other situations, signing without encryption can be common and good practice. The typical example is software distribution. In some Linux distributions such as Debian and Ubuntu, software packages are signed (indeed using the OpenPGP format), so that you can be sure that you are installing genuine packages without backdoors inserted by malicious third parties; but the packages are not encrypted because they are, ultimately, public data.

Note that a signature from you can, be essence, be used as proof against you. Therefore, from your point of view, signatures are good as long as they are signatures from other people when they send messages to you, and not the other way round.


If I set up a home web server, will computers that use my wi-fi be vulnerable?

L2 is also vulnerable if everyone can access your home server using public IP (if you have one). As long as you set up a home server only using private IP (NAT), it will be accessible only to people who connected to your network, but including people who use your wi-fi since they are in a same router. If it's your only option, just make sure that your wi-fi is secure enough.

Another option to build a private home lab for security testing, you can use virtual machine, so you can test anything to your virtual machine without any risk.


When you connect to an open public wifi network without any security settings such as your local Starbucks, everything transferred over that network is sent in plaintext. Anyone sniffing the network could intercept the traffic, and potentially modify it. If you're connecting to one of these networks, it's best that you then connect to a VPN to encrypt your traffic so that it can't be captured or modified.


Could a malicious JS file pointed on URL/URI attack the browser/computer?

Yes there are known attacks of this type. The site you are trying to visit is one. That's why your browser is telling you not to visit the page.

Javascript files included on pages are always executed by the browser. That's what Javascript does. Whether or not it has the necessary privileges to do something malicious is where the battle is at. It is unlikely that your browser is going to allow it to do something it shouldn't be able to without your permission. The real problem is that it could prompt you for something and lie about what it is prompting you for tricking you into granting it permission to do something harmful to your system. Tricking you into downloading/running some piece of local software is the most likely attack vector, but there are certainly others.

If your question is "is this message baloney" or "should I take this message seriously", the answer is plainly the latter. Yes of course there are known attacks of this type, that's why it's warning you that something is the site code looks like one!


Higher risk of no certificate pinning on mobile apps vs web apps?

TL,DR: The protection of certificate pining is the same: almost none.

The risk is essentially the same, and Certificate Pining is not something that will deter any determined attacker. As soon as part of the code is not executed inside your own environment, you have no control whatsoever. Just look at all blockbuster games and their protections, and the myriad of cheating tools bypassing every single protection: anti-debugging, certificate pining, checksumming, and everything else.

In case of web applications, pining is mostly pointless because the attacker will have the entire source code readily available all the time, and every browser ships with a full fledged debugging environment. In this scenario, certificate pining will be defeated with a well placed breakpoint and a variable change.

On a mobile application, the path is a little longer. The attacker will usually need a rooted or jailbroken phone, and will change the application to use another certificate, or to bypass the check. Either way, isn't nothing a dedicated attacker would have any difficulty doing.


gpg --fingerprint prints out completely different fingerprint

GnuPG generally resolves subkeys to the primary key if a subkey is passed as argument. This might be especially surprising when specifying an encryption subkey: GnuPG resolves the subkey to the primary key, and might actually choose another subkey for encryption (selecting the newest encryption subkey).

For listing a key, this is always performed, for some operations like encryption you can append ! to the subkey's ID (ie. D72AF3448CC2B034) to explicitly select this key and disable the primary key lookup.

To display subkey fingerprints on the command line, apply the --with-subkey-fingerprints option:

$ gpg --list-keys --with-subkey-fingerprints D72AF3448CC2B034
pub   rsa4096/0x12F5F7B42F2B01E7 2017-02-09 [SC] [expires: 2027-02-07]
      F554A3687412CFFEBDEFE0A312F5F7B42F2B01E7
uid            [ unknown] OpenVPN - Security Mailing List <security@openvpn.net>
sub   rsa4096/0xF80E8008F6D9F8D7 2017-02-09 [E] [expires: 2018-03-06]
      E6CAF699521B9B5E57A5C31BF80E8008F6D9F8D7
sub   rsa4096/0xD72AF3448CC2B034 2017-02-09 [S] [expires: 2018-03-06]
      B59606E2D8C6E10B80BE2B31D72AF3448CC2B034


Can I use more than one encryption program to encrypt my computer files or will it cause conflicts?

If you mean the filesystem is encrypted, this provides protection when your computer is off or logged out, as an attacker would need to decrypt to gain access to files.

It does not provide protection once the machine is logged in to your account - as the decryption happens as part of normal usage, so if you have files you wish to protect from attack on the system when it is logged in, encrypting them is a good idea. This type of attack could be shoulder surfing, where someone gets your password by watching you type it.

Every layer of encryption will add to the time it takes to access the files, so you need to look at your threat model and requirements.


Is cloud storage safe to use if I use gpg and is my method secure?

Yes, this secures your data from Google, sync.com and from anyone trying to grab your data while it is in transit to Google.

Three things to think about:

Your lastpass password is far shorter and contains (the way it sounds) far less entropy than the one that protects your gpg tar file. Someone attacking this scheme would therefore most likely attack your lastpass account (since now it's public knowledge that your password there is weaker).
It sounds like you're using GPG in symmetric encryption mode (more on an alternative at the end of my answer). So: What's to stop a disgrunted lastpass employee with a bit of technical knowledge to steal your gpg password and sell it to an interested party at Google? Or if you find that problem too theoretical, what about an attack on the lastpass service which steals millions of user passwords and publishes them? Since you've conveniently added a note about where the encrypted files are located, you're basically handing your encrypted files over to anyone who can access your Lastpass account (well, in theory, anyway - he or she still has to get your Google Drive password...)
You're splitting your file into multiple files. Why exactly are you doing this? If you lose just one, you're running the risk of losing all your data. Say you lose file 20 (out of 200): You've lost all the content that was stored in files 20-200 forever. Keeping everything in one big file might make up- and downloading a bit more difficult, but it reduces the risk that you lose one of the files.

A few suggestions

Point 3 is also a problem with a huge file that accidentally gets a single bit flipped in transit. I'd think about redundancy a bit. There are ways to add error correction without having to double the size of the data. (I think some compression programs support it natively, even though you can't expect them to actually compress your .tar.gpg file...). Confidentiality is all well and good, but your scheme is a backup scheme, so you should also think about availability.

I would also suggest not storing your GPG password on an external service (Lastpass). If you're afraid of losing the 100 character password, write it down on a physical piece of paper and put it in a safety deposit box of a bank you trust.

Also, this might seem paranoid, but I wouldn't use the same passphrase over and over to encrypt your gpg files. Instead, I'd genereate a file containing a number of truly random bytes whenever I needed to upload a new backup and use that as a key for my gpg'd tar file. I'd then encrypt this random file with my 100 character passphrase and keep it on my computer, send it along to be stored at google / sync and maybe back it up to an additional location. (Basically, I'd create a session key with which to encrypt my data and use the 100 character string as a master key to decrypt the session keys). You can automate this fairly painlessly, and it gives you forward secrecy in case one of your backup session keys is compromised and the ability to decrypt any specific backup without losing control over your master key.

Finally, if you're really just using Google Drive as a backup and don't really need to decrypt the data except in emergencies, you could think about using gpg in it's public key cryptography mode. Make a backup key pair, and then keep your private key safely offline (in a bank deposit box, on a CD ROM, printed out on a piece of paper somewhere for safekeeping) while using the public key to encrypt your symmetric session keys (using public key cryptography to encrypt with gpg would make the manual session key step seem redundant - I'd still do it for better forward secrecy). So you'd never have to worry about your master key (private key) getting compromised by cyberattacks, even if you stored your public key at LastPass. Even if they stole it, all they could do with it is encrypt more data; they couldn't use it to decrypt your session keys.


MD4 or MD5 speed depends on data or just on data size?

As far as performance is concerned, the time to compute an MD5 hash or any other cryptographic hash depends solely on the number of bytes. It doesn't matter what the bytes are.

Note that memset(buffer, ' ', sizeof(buffer)); doesn't create an “empty buffer” — there is no such thing as an empty byte in memory. It fills the buffer with space characters, which are bytes like 'a' or any other.

Security-wise, the time to compute a hash can vary very very slightly depending on the data. This may allow an attacker who doesn't know the data but can accurately measure the time it takes to hash it to obtain some information about the data. For a hash computation, timing attacks are highly unlikely to work in practice, because there is little in the timing that depends on the data. Timing attacks are mostly successful on operations on large integers involved in asymmetric cryptography, and mostly when the attacker can influence the data and the execution speed. For example, if the implementation uses a table that doesn't fit in a single cache line and the attacker can run code on the same processor, the attacker might try to use the cache in his own process, so that the hash computation keeps fetching parts of the table from RAM, allowing the attacker to observe when RAM lookups take place. The implementation can counter that by being cache-oblivious.

In practice, I wouldn't worry about timing attacks on hash computations. Hash comparisons, yes (when comparing two MD5 hashes, one of which is secret, you should compare all 16 bytes and not stop at the first difference). Number of hash computations or comparisons in an algorithm that involves many such, yes. But not for the hash computation itself.


How can a web API for a mobile app be protected from unauthorised access?

Any secret you may have in a mobile app is lost to the user. You can't secure anything that is given to the client. On the other hand, a request to your API is the same from any source. The client can send anything.

Given these assumptions, it is impossible to make your API only work with your client. Anybody can extract any identifier from your client and make another app with the same identifiers or secrets to query your API, and you have no way to tell who (what piece of software) the caller is.

And from here, I think it's probably a legal question, you can create a suitable Terms of Service to prevent that and talk to lawyers what can be done to gain legal protection.

Technically the best that you can do is probably using API keys, so even if you don't want to identify individual users, you could still have them create API keys for themselves to connect to your API. This way, you could at least control and possibly ban API keys that you think are against your ToS, and you could also deny issuing a new API key to offending users. But for this you would also need facilities to actually try and find out who those users are (which API keys, technically), and that will not be exact science.


Is HTTP Strict Transport Security needed when only listening on port 443?

It doesn't matter what your server does. For all we care it could even be down, and MITM attacks would still be possible. All it matters is what the client does. If your client makes insecure requests or accepts untrusted responses, then a MITM becomes possible. HSTS is used to make sure that your client only uses HTTPS to connect to your server, which means it will always use secure requests and accept trusted responses.

Imagine visiting the following malicious HTML page:

<img src="http://www.your-server.com/foo">

Without HSTS, your browser will send an HTTP request which can be intercepted by the MITM, who could steal the authentication data that is automatically sent in that request (cookies, headers, etc.)
With HSTS, provided that your website is already in the list of domains that have HSTS, your browser will refuse to make that request in plain HTTP, and the MITM won't be able see the content of the request or try to impersonate your server.


Don't know really how to explain it differently as I think the nmap page explains it ok, but basically...

Some hosts respond to pings if they are online (I.e. ping www.google.com and you get a reply.)

Nmap tries pinging them, if they respond nmap continues scanning and you get your result. If it gets no response it says 'hmm they must be down, well no point wasting time scanning someone who doesn't exist' and exits.

Now some hosts are alive, but configured not to answer to pings. Under normal circumstances this means nmap would simply not scan them thinking they were down. If you specify -Pn it skips this initial stage of checking if the host is up and basically says 'well I've been told to scan no matter what, so even if I think it's down* my stupid human operator is making me do it anyway'. It then tries to scan and actually gets results because in reality the host is alive.

*saying it thinks its down is slightly incorrect - if simply ignores the check in the first place.

Summary - skips checking if the host is alive which may sometimes cause a false positive and stop the scan.


AFAIK, the standard way is to use asymetric keys for signing:

the private key is only known by the sender
the request is hashed with a standard algorithm, and that hash is encrypted with the private key to form a signature which is transmitted with the request
the server uses the public key to decrypt the signature and control that it corresponds to the message.

That way:

no secret has to be shared
no secret is transmitted
assuming a cryptographic secure hash, it is admitted that it is not possible to build a request corresponding to a given hash


Attacking encrypted storage vs attacking memory

Stealing data from the memory is definitely easier than stealing it from an encrypted file.
You can take a dump of your memory and then scan it to search the password.

On a side note, I believe the bigger risk here is that there is a very simple mapping between the seed and the password. Also, the seeds seem to be predictable. Once that is compromised, do you have a safety/fallback mechanism to protect other passwords?


Is there any point in activating domain privacy after the fact?

Sure there is.  All forms of security are about making the attackers job more difficult, not impossible.  A physical safe doesn't stop the bad guy from getting the stuff inside, it just makes the attack take long enough to catch them in the act, or increase the cost to get the goods beyond their value.  All security controls work like this.

If your cost to deploy a control in time, money, or any other resource, is less than the value it protects, it is a worth-while control.

Enabling privacy protection now stops future folks from looking up your information.  Sure, there are historical DNS systems, but some people you are trying to stay private from won't know about that.  Further, as time passes, your information may change, and will remain protected, while the history services don't get those updates.

So the question to you is, "Is the time/cost/effort of setting up and maintaining privacy protection worth this 'partial' future cloaking of your identity?"  Only you can make that evaluation.

I'd claim that since the question was phrased as "is there any point" the answer is "yes."  That point may, or may not be a valuable one, for you but there certainly is some point in turning it on after the fact, despite the existence of historical archives.


Does password expiry provide any benefit at all (when using randomly generated passwords)?

90 days is more than enough to profit from stolen credentials (however strong they are). Moreover, most passwords will vary only by a digit or two when changed, so even a password older than 90 days will allow an attacker to guess the new one fairly easily.

If your passwords are strong (randomly generated by password managers) and one still manged to leak and find its way into the hands of an attacker, the solution is to fix the source of the leak, not to blindly update the passwords. Changing the passwords will not prevent new passwords to leak in the same way.
It would be wiser to prevent password guessing attempts and to try detecting abnormal authentications. Using proper 2FA could also better mitigate passwords leaks.

In the same time, this policy pushes the users to make passwords easier to remember, thus easier to guess by an attacker. All thing considered, the policy mandating to update the passwords regularly weakens the overall security provided by the password protection. That is why Microsoft is planning to remove this policy from of Windows 10 starting with the may 2019 update. The NIST also recommends against its usage for password that needs to be remembered.


Your assumption is correct. Why this happened? You can only speculate. Might not be a purposeful action at all. Maybe a malicious person hopes someone does exactly what you describe. The zip might have a name that motivates someone to do so like "your-bosses-private-emails.zip" or sth like this.


Can I tell if a python script is secure from transmitting sensitive data by analyzing its imports?

You simply can not assume a program or script is safe solely on their imports.
It is to easy to either combine functions or to abuse some 'safe' feature to do something unexpected (like using time queries to transmit data to a command and control server, or tricking the system to running curl with a payload of your data)

The only way to know is to do a proper code review of the script and than evaluate if a script is 'safe' or not (safe being what you define as save to use)
there are no High risk imports being added to the script in your post, but you would also have to check for bash / system / eval commands that 'break out' of the python environment


how to protect my linux pc from wifi sniffing

Should I use a wifi anti sniffer...?

These work by detecting responses from the sniffing card - it's not hard to prevent any packets being sent out.

  would be the only solution the use of a VPN to protect my packets?

This doesn't stop the packets from being sniffed - it only prevents them from being read or modified. As such it's no different from other forms of encryption (e.g. SSH, SSL). You also need an end point for the VPN before you can access any services outwith the VPN. If you don't trust the people you live with, do you trust the people who manage the VPN end point? Although many routers have VPN capabities I've only ever seen this for the internet facing side - not the LAN side - so unless you know differently your only practical solution to the problem is to build your own router with VPN, DHCP, NAT.


Can a ransomware "destroy" git remote repositories?

Yes. A Ransonware can "destroy" your files locally. As for the server, this depends on the configuration. It would be interesting to use a password in the key to auth with git. Ransonware can read your files, but it will not be possible to send remotely.

Recommendation: Use the ssh key with password and do not use automatic authentication.


Calculate Content-Length (HTTP Request Smuggling)

Content-Length represents the length of the entity-body in bytes but
  where does the counting start?  How was 13 derived?

0 is the first character counted in your first example, but newlines in HTTP are usually CRLF (\r\n) which is two characters.  Accordingly:

0\r\n            3 characters
\r\n            +2 characters
SMUGGLED        +8 characters equals 13 characters (no trailing CRLF)


How do I configure Terminal Server (and clients) for use over untrusted Wifi networks?

The old versions of RDP can do some encryption, but it is vulnerable to Man-in-the-Middle attacks for lack of validation of the server public key (older versions used weak encryption as well, or even no encryption at all except for the password sending).

Beginning with version 5.2 of the protocol, SSL/TLS can be used (the TLS traffic is encapsulated in the RDP-specific transport protocol), thus with a server certificate which the client can validate; this gives the needed protection against attackers, including MitM. The server must be Windows Server 2003 or more recent; as a RDP server, Windows XP cannot do that. However, the RDP client which comes with WinXP SP3 knows this protocol and can use it.

An alternative is Terminal Service Gateway, which is an extra service which reverts the structure: an SSL/TLS connection, on port 443, and inside it the RDP protocol. The TSG must be Windows 2008 or more recent. There again, the client in WinXP SP3 can use that.

Unfortunately, alternative clients for other operating systems, like rdesktop, do not support RDP 5.2 or TSG yet (if they do, I would love to hear about it). The Microsoft client exists for MacOS X (it comes with Office, it might be downloadable separately) but not for Linux. For proper security of RDP with multi-platform support, you will need a VPN.


Do spaces in a passphrase really add any more security/entropy?

No (with a minor exception at the bottom).

The passphrases "correct horse battery staple" and "correcthorsebatterystaple" are equivalent entropy-wise.  Choosing to put spaces in an incorrect spot or sometimes including spaces and sometimes not including spaces will give you a few extra bits of entropy; but its not worth it for the extra difficulty remembering it.  You'd gain a few bits of entropy for the entire passphrase for weird spacing pattern; while just adding another word would add about 13 bits (assuming a diceware dictionary of 7776 words corresponding to 5 rolls of a six-sided dice; note that lg(65) = 12.92; lg being the base-2 logarithm).  (There's no disagreement between my answer and Thomas's; an attacker would have to check for passphrases both with and without spaces unless he had extra information about whether you tended to use spaces in your passphrases).

Beware the distinction between random words and meaningful sentences.  A passphrase "quantum mechanics is strange" is much lower entropy than say "heat fudge scott canopy"?  Why?  In meaningful English you have patterns like certain words combine frequently (quantum mechanics) or certain patterns must appear to be grammatically correct (subject, predicate, subject complement) that in principle could be exploited by a sufficiently sophisticated attacker (even though I am not aware of any cracking algorithms that currently utilize this).  The informational entropy of grammatically correct written English is about 1 bit per character so the first passphrase has ~30 bits [1], while the second passphrase has about 4×12.9 ≅ 52 bits of entropy; so would take about 222≅4 million times longer to crack.

Be wary of incorrect analyses like http://www.baekdal.com/insights/password-security-usability that make many fundamental information theory mistakes.  E.g., "this is fun" is incredibly weak being comprised of some of the most common English words in a syntatically correct sentence that is very common ('this' ~ 23rd most common; 'is' ~ 7th most common; 'fun' ~ 856th most common word) [2].  If you tested just three random words from the top 1000 english words, it would take you only 1 second to crack it, assuming a modern GPU and you have acquired the (salted) hash.  This is roughly equivalent to a 5 random alphanumeric characters (not counting special symbols).  If you search google for the quoted phrase "this is fun" it appears 228 million times.

EDIT: Minor exception: in the rare case when consecutive words in your passphrase form another word in your dictionary (or your attacker's dictionary), then not having spaces (or another separator) between words lowers your passphrase's entropy significantly.  For example, if the random words forming your passphrase were "book case the rapist" and you had no spaces, an attacker could get in by trying  all combinations of just two words 'bookcase therapist'.


The IP address is for data.logentries.com:

$ dig data.logentries.com|grep 78.79
data.logentries.com.    98  IN  A   46.137.78.79

logentries.com provides log management and analytics and it appears someone at your site has signed up to it.


Bring your own phone to a (new) job: Consequences?

Just wanted to chime in and say that the list you have there isn't entirely 100% accurate, but it is close.

Keep in mind that this will vary per MDM vendor and mobile OS, but MobileIron can see your location if your employer enables the functionality and you choose to accept sharing your location data.

  How exactly is this done? They just configure something in settings,
  and I supply my lock screen passcode to give them permission?

Your employer should direct you to a portal where you register your device and install the MDM application. The employer cannot see/extract nor does it know your personal PIN.

  Can any of my behavior or data, outside of company-supplied apps, be
  observed?

Behavior - yes, if you take into account location data.

Data outside of company supplied apps - no.

However, your employer can see a list of all apps installed on your phone, so you may think twice before installing any "questionable" apps.

  What apps or "root level" utilities can I expect to have installed?

Not sure how to answer this one exactly. It sounds like you are asking if they can install the equivalent of a rootkit on your phone? Realistically I'm inclined to answer no.

  Will any restrictions be placed on how I can use my phone, or on the
  apps I can install?

Yes, your employer can black list apps.

  Is there anything else I need to be aware of?

Yes, please refer to the infographic below. (location)


Can a hacker access smartphone data while locked?

This depends on the implementation and configuration of your smart phone, but smart phones can be pretty secure. In the FBI–Apple encryption dispute, the FBI took more than a month and spend more than one million dollars to access the data on an iPhone.


Is there a way to execute XSS in an HTML img tag with SVG?

No, it's not. Although SVG files can contain JS (see this), these will only get executed if:

the user directly visits the .svg file in their browser
the image is embedded within <embed> tags.

Modern browsers will never execute scripts in SVGs if it's within <img> tags.

And even in the two cases above, the server can provide CSP headers that stop the execution of such scripts.


I'm going to answer both your questions in a kinda non-specific way, but bear with me.

Your first question is "I'm putting in an IDS, what should I tell it to do?"

Well, you're doing it backwards, but don't worry - this is a common security confusion.

An IDS, like any security system, is not a magic wand. You don't just install it and everything's hunky dory. It's a tool, that you use to treat a specific risk.

So you have to start with a risk analysis. Identify all the threats you face, and the vulnerabilities in your setup that those threats might use to harm your assets. Those are the risks. Identify the likelihood of those risks happening, and the harm they could cause. Those are the risk levels. Now you can tell which risks you are happy with, and which you need to treat.

For example, if you decide that "a NOC employee inadvertently brings a compromised computer onto the network" is a risk that is currently at an unacceptable level, then you sit and figure out a way to fix it. Part of that fix might be to have an IDS sitting inside the NOC looking at all the traffic going by. Not all of it though - you'll probably also be looking at improved scanning of machines before they get in, better processes for employees, etc. etc. You pick the control based on how well it reduces the risk.

Then you do the same process again for "exploits against the web server" and all the other risks your analysis found.

The key is: Identify and understand the risk first, and then put treatments in place to reduce it.

Your second question is "I have a strong perimeter, do I need an IDS behind it?"

There's an important security principle called "defence in depth". Basically, don't rely on one control to protect you. Layer controls, and think about what happens if one fails.

Sure, you have a strong perimeter, and little is going to get through, and thats good. But if something does, wouldn't it be nice to have an IDS there that sees it?

Of course, the question is if it is worth the expense. Snort's free, sure, but your time isn't. That's something for you to work out, based on the risk level - how likely is something to get through, how much harm could it do? Maybe it's worth it, maybe not. That's a pure business decision.


CVSS v3 was released in 2015 so vulnerabilities prior to that were only rated according to the then-current CVSS v2. Also, my guess would be that "N/A" in this context stands for "not available" instead of "not applicable".
Of course, you should consider CVEs prior to 2015.


Layer model for information security - scientific name?

The term you are looking for is defense in depth.

It's a term that describes security defences structured so to be layered around what you want to protect; this includes not only security of all ISO/OSI layers but also e.g. physical security:

server room with locked doors
security badges to access the building
security guards inside and outside the building
background checks on personnel
personnel training against social engineering attacks
insurance for theft, loss of service, legal issues etc.
anything else for which an attack is feasible

Note that a protection model based only on information security, without e.g. physical security, is doomed to failure.


How to do a virus scan before post attachments in asp.net application

My advise is to configure a directory that your AV scans whenever a file appears there.

Save your attachment there, and attempt to read it after it's been saved. If it can't be read after it's been saved there, or if it doesn't exist there anymore, then it is a potential virus that needs to be examined further.


A slightly radical approach, but if you really want to ensure that no (unencrypted) information from those text files ends up on non-volatile memory drives, I recommend you to use a Live CD (such as Knoppix), and only from there, mount the hard disk, copy the encrypted files to a ramdisk (everywhere else will be in-memory), decrypt and edit as needed.

The main advantage of using a live disk is that by having the whole OS in-memory you are barring most of the potential leaks, such as unexpected temporary files or the OS deciding to page the text editor. You will mostly only need to:

Ensure that the distribution you are using in the Live CD does not automatically mount a swap partition you might have in your disk.
Copy the encrypted file itself to a different location than the mounted drive, for safely decrypting and editing. If you feel extra paranoid you could even unmount the normal disk before decrypting and remount after deleting the plantext version, but it isn't needed.


Do I always have to overwrite EIP to get to write on the stack in a buffer overflow?

You don't always have to overwrite the return address in order to exploit a stack based buffer overflow (also has a great diagram of the stack layout).  With a stack based buffer overflow you can corrupt other variables declared in the local scope of the function which can produce interesting results.

For instance lets say there is an authentication funcation:

//I like to think of the return address as sitting on top of every function.
//void * ret;
boolean login(char * password){
  boolean is_logged_in=False;
  char buf[5];
  strcpy(buf,password);
  if(strmp(buf, MASTER_PASSWORD)==0){
     is_Logged_int=True;
  }
  return is_logged_in;
}

The stack layout is such that is_logged_in is above buf.  The stack frame,  which contains the return address is somewhere above is_logged_in.   The return address will become the EIP only when the function returns.  But it isn't necessary for the attacker to corrupt the stack frame in order for the attacker to take advantage of this buffer overflow.  Simply overwriting the value of is_logged_in with a value that equals True will allow the attacker to authenticate without knowing the value of MASTER_PASSWORD.

In this buffer overflow vulnerability, the use of: ASLR,  NX Zones, and Stack Canaries does not prevent exploitation.  In fact it is also likely that the same exact exploit will work regardless of platform (windows/linux/arm/x86...).

(Disclaimer:  I think I read about this exploitation method in "Hacking: The Art of Exploitation")


What is the purpose of a requesting a non existent resource

I agree with the others that this is probably not web app hardening but instead per this forum post

https://www.wilderssecurity.com/threads/strange-links-from-my-banking-website.361064/

Is probably

"... just plain visitor tracking evilness..."

  Did this happen to be from a capitalone.com domain? I happened to see
  a blocked script from 127.0.0.1 plus my public IP in my NoScript
  listing. This kind of freaked me out, since (of course) it was our
  credit card site.

  I did some digging, and that appears to come from an 'fp_AA.js' script
  located at:

  https://login1.capitalone.com/resources/jscript/fp_AA.js

  I de-minified that script, and posted it here:

  http://pastebin.com/P3WiGzDG

  The relevant code calling the image is at line 509:

  ProxyCollector.doAjax = function (k, l) { var j =
  document.location.protocol + "//" + k + ":" + getRandomPort() +
  "/NonExistentImage" + getRandomPort() + ".gif";

  So, it appears to be some kind of browser fingerprinting/proxy
  collector JavaScript. Perhaps it's trying to do an nmap-style TCP
  fingerprint of the response when it sends an HTTP request to a closed
  port?

  Also interesting is that I'm seeing those UUIDs listed on line 459
  mentioned at:

  http://www.browserleaks.com/javascript

  And there's an interesting read from Mozilla about browser
  fingerprinting at:

  https://wiki.mozilla.org/Fingerprinting

  It doesn't appear to be malware, just plain visitor tracking evilness.


Is there an organization that reviews/approves crypto implementations?

Since 1995, NIST has indeed also certified implementations, via the Cryptographic Module Validation Program (CMVP) that validates cryptographic modules for adherence to FIPS 140 standards.

OpenSSL is open source and the OpenSSL FIPS Object Module has been validated via this program: OpenSSL: Important Notes about OpenSSL and FIPS 140-2.

  The OpenSSL FIPS Object Module
  validation is unique among all FIPS
  140-2 validations in that the product
  is "delivered" in source code form,
  meaning that if you can use it exactly
  as is and can build it (according to
  the very specific documented
  instructions) for your platform, then
  you can use it as validated
  cryptography on a "vendor affirmed"
  basis.

Note that, as they say, "it's complicated".  So do check out those links carefully and be prepared for frustrating interactions between the technical and bureaucratic challenges.


Should password recommendations be different for devices, networks, and internet?

A good password is a trade-off between several parameters:

Value of that which is protected (this should condition the effort invested by potential attackers).
Cost of brute force (this depends a lot on the target, e.g. some will allow offline attacks on a hash value, while others limit attackers to online attacks only, at some maximum server-enforced rate).
Ease of remembrance.
Ease of entry (e.g. mixed case/digit passwords are difficult to type efficiently on a smartphone).
External constraints (minimum size, maximum size, strict and often misguided rules enforced by an overzealous admin...).
Extent of the password power (e.g. SSO makes passwords applicable to many systems; password reuse too).

Since it is a trade-off, a password will never be generally perfect.

How often you type the password is an important parameter: the more often you type it, the easier it will be to remember it. For a password which is entered on a daily basis, go for a sequence of random letters (chosen uniformly and independently of each other): this will speed up entry because you can reach a very decent entropy level in relatively few characters (with only lowercase letters, 10 characters already get you to 47 bits of entropy).


How to verify the authenticity of Facebook users?

Facebook relied on user generated "abuse reports" as leads for identity investigation. Meaning, you can report a suspicious account and it will be review by FB team (I`m guessing we are talking about log checks, "believable" friend pool and etc)

They got no automatic policy for account identification besides the following:

Feature overuse: Simply Checking the rate of usage for features (i.e. Too many messages/reoccurring content)

Unwanted contact: High "deny friendship" rates/repeat "friendship request" are deemed suspicious.

I actually think they got the right idea here, as behavior-based challenges are probably the best way to find fake FB users.

There are maybe few other things you can do (having a a "suspicious contact pool" signature for example and some Bot challenges like JS/Header and others) but, for me, the main issue here is their Enforcing Policy.
Currently, you have to work pretty hard to get banned from FB, and in the end - with all of their cash flow problems - a large user base is still Facebook's main claim-2-fame and I don`t see them messing with it any time soon.

As for the numbers, I`m assuming they've just based on an avg. or previous fake/real user statistics.


Snort / PulledPork event filter via modifysid.conf not filtering traffic

Changed they type from "threshold" to "limit" and it seemed to help.


Why do we not require websites to have several independent certificates?

why do we not require websites to be validated by, say, 3 certificates
  of independent CAs?

Here are a few reasons:

Cost.  Purchasing certificates is already somewhat expensive*; tripling that expense - and forcing purchasers to wade deeper into the pool of potential CAs, where they usually start at the cheap end - would not be welcomed.
Complexity.  Currently, if a certificate expires, the site is offline or degraded until IT can scurry around and fix it.  It happens surprisingly often given that expiration dates are known and can be planned for.  Your proposal would triple the number of certificates that need to be installed correctly, that need to be replaced before expiration, that need correct certificate chains...  Some of this stuff is hard enough today with just one CA!
Compatibility.  The TLS protocols do not specify a method of operation where multiple certificates must be validated, so you'd have to update or replace the protocol being used, which will take years.  There's no way to specify to the client that this particular server requires multi-certificate validation, so downgrade attacks are trivial - again, you'd need to create a method, and then wait years for support to percolate out.
Certificate Pinning.  Your idea says "Let's assume the CA model is broken, and as a solution increase our dependence upon the CA model."  If one CA can be compromised, why not two (assuming a 2/3 majority wins in your model)?  At that point you'll start saying, "Well, obviously we want to trust Entrust more than the Consolidated Republik of Tadpolistan" - at which point you've reached Certificate Pinning, which is already a thing.
WoT else? The other natural conclusion you'll reach, when you decide that some CAs are more trustworthy than others, is that there should be a method of incorporating reputability.  This is called the Web of Trust, and is a competing model to the Centralized Trust of CAs today.  One implementation of the WoT method is the Perspectives Project, which is an interesting approach to the same problem you describe (and which works in complement to, and in compatibility with, the existing CA model).

* Before someone jumps up and says "Startcom!" or "Let's Encrypt," please remember that businesses drive the CA model today.  They pay significant amounts of money, and some of them purchase thousands of certs annually.  The cost impact needs to be considered against all players.  (And even on the low end, if you want a free cert, now you would have to find 3 reputable free providers, when finding one was already a challenge.)


Is amazon.com allowing authentication based on browser cookies only?

This allowed other people in the house to watch prime videos ...  My main concern is that this is a security issue on shared computers.

Let me rephrase this a bit differently:

You like the behavior that the authentication is kept over browser close, since it allows you to share your computer with others so that they can watch video with your account.
You don't like the behavior that the authentication is kept over browser close, since it makes it possible that your shared computer can be used by other to make purchases on your behave.

Isn't the real underlying problem that you share your computer and thus implicitly your account with others, while only marginally trusting these others? If you would not trust the others at all then you would not share the computer in the first place. If you would trust them fully then you would also trust them to not make purchases on your behave or you would trust them to actually make such purchases but only the ones you've agreed to.

So far you've relied on the way it was implemented (but not documented?) by Amazon to have such partial trust in exactly the way you need it possible. The changed behavior now makes it more inconvenient for you, while making it maybe more convenient for others.  Security and convenience are unfortunately usually a trade-off and there is often not the single one trade-off which fits all users best.

Apart from that: it might even be that the change in behavior you see is not actually due to changes at Amazon but due to changes in the browser or browser settings or changes in your behavior. The only way to detect if a browser was closed and restarted is to use cookies with no explicit lifetime  which have a lifetime until the browser closes. Only, modern browsers might actually preserve these cookies if you have session restore enabled - again, since this is more convenient and since most users actually expect to be able to continue with a restored session directly.


Windows system password hashed - see which hash is used

Currently windows uses NTLMv2 to store the password, but for backward compatibility some system uses LM hashes. Now it is recommended by the Microsoft to not to use LM method to store the password because of its weakness towards brute force attacks. If you want to see currently which method is used then you have to navigate to  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA. You will see the entry named NoLMhash with the DWORD value 1. It means LM hash storage is disabled in your system.

On the same location you can see the name LmCompatibilityLevel edit that and see the value associated with it and if the value is 0, 1 or 2 then force the system to use only NTLMv2 by changing that value to 3.

If you are in the LAN then you can check which method is used by your system to communicate to the servers by capturing the packet using any ethereal tool i.e tcpdump, wireshark in the network.

Refer this link to understand the compatibility


Is there any way to detect caller ID spoofing?

Although I have no firsthand experience, I've read of this being done by forwarding calls to a toll-free number, which then (by virtue of being toll-free) receives the true calling number through ANI (which is distinct from Caller ID and which supposedly cannot be spoofed) and finally forwards back to the original number.

For example, the TrapCall service mentioned here appears still to be in operation: http://www.nytimes.com/2009/03/15/us/15call.html


I feel like it's impossible to learn reverse engineering

So let me preface this with "I'm not implying you're a child"

Often when I teach kids about CIS and they hear what I do for a living, the first question is

"How do I hack?"

I'll tell you the same thing I tell them. Hacking isn't a thing you learn as much as it is the result of years of experience in a series of topics that relate to security.

Often you'll find people break into the security field coming from software backgrounds and network backgrounds. I started on my security path a few years ago by attending defcon, derbycon, and other security related events. I learned that if I wanted to do it professionally then I needed to dig deeper. I learned there was no magic knowledge that made you a security professional. Just hard work and learning about what it takes to make things secure.

After building lots of Arduino projects, setting up lots of webservers from scratch, building lots of websites from the database up, taking (and failing mind you) my OSCP, I finally got to a point where I felt comfortable calling myself a security software engineer. The company I worked at during that time had a security champion program for engineers. They gave a single team member more advanced security training to be the team security engineer. I did that and I loved it.

About a year and a half ago I took the leap and got a job building intrusion detection software and I love it. Most of my work is standard coding but I do get to apply my security knowledge on a regular basis in various ways.

I guess my long winded point is, keep learning. You're doing it the right way by learning different technologies. Check out my blog https://www.DotNetRussell.com and you can see the projects I did that led me to where I'm at now.

Keep learning. As mentioned in the comments, security is hard. That's why there's such a demand for it! It's really rare that it comes easy to people. The people that you see that are experts in the field are there because they spent years and years grinding that hard knowledge.


very bad malware that masquerades as spyware?

Yes. What happens is that something gets a foothold on the system, phones home, and then is bootstrapped with a rootkit that is suited to the browser or operating system.

Once compromised, the attacker can deploy different payloads - this month it might be a bitcoin miner, next it could be ad injection into the browser, whatever it is that they are being paid to do.

It doesn't always happen, but I'd say it is pretty common. This leads us to conclude that to be certain your machine is not compromised, always rebuild, no matter how mild the infection might appear to be.


Understanding port scanning with firewall enabled

To explain things in a simple manner: ports can have 3 general states:

Blocked - (by firewall or any equipment between source and destination) - nothing gets through in either direction. Everything is denied.

Normal - (default state in most cases) - you can request connection towards anywhere and they will work, but incoming connections towards you are not permitted. A connection will work if you (the source) initializes it. If someone from outside initializes it, it will not work.

Open (sometimes called forwarded such in the case of NAT) - all connections can go through both ways. Anything incoming via such port will be allowed.

If an application is active and listens to a port, it will only be able to receive incoming connections if the port state is Open, it will be able to initialize connections if Open or Normal and will not be able to do anything if Blocked.


The problem is that someone was able to register the subdomains.

I used https://dnsdumpster.com/ and got the following data:

outdoorsthatsoftcore1.beginnergolfswingtips.com
31.210.173.89
hosting.eurohoster.org
AS197793 LLC Gigabit
Russian Federation

From the map, it shows that the other DNS has A records.

You need to work with the support team of whoever runs your DNS (likely to be Hostgator) to get control back of your DNS and remove the A records of the malicious domains.


True?: "Nearly all encrypted passwords are stored with the last character in clear text"?

No, I don't think this is true. News coverage gets this wrong all of the time, probably because its not an easy topic for an outsider.

It all starts with the term encryption. If you are really encrypting a password, you are most probably doing something wrong. Passwords in the context we are talking about are used for authentication. There is absolutely no need to have them available in the clear. Currently the best practice is to iteratively hash a password with a user specific salt. This process is practically irreversible and I don't see any way why a single character would be more prone to be reversed than any other.

However, if you don't follow this approach and doing something nasty like storing passwords in the clear or only storing them encrypted, it might very well be that passwords can be accessed in the clear. I don't see a way why the last character is more vulnerable than others, though, so I would strongly argue that the statement mentioned in your question is simply not true and someone was talking about something he has not understanding of, or at least oversimplified matters in such a way that they are simply false.