The main concept of your flow (magic links) is one of the more well known password-less alternatives for authentication. The general consensus seems to be that the security of such schemes (as has been noted in comments) is not any worse than that of a system that allows 'forgot password' email reset mechanisms. This does make sense considering that the point of failure is now in the email part.

Email servers are generally not encrypted and mail can end up stored in insecure locations such as the user's mail client. You will also have no control over how securely the user sets up their email account. It might also be useful (since it's often compared to it) to remember how hard it is to implement a password reset securely. In the end whether or not this should worry you is really dependent on your threat model and the value of your app's data.

Sources that I can find that support magic links and other password-less schemes are mostly from vendors who have a vested interest in pushing their own implementations of this system (e.g. Auth0, okta) and there are some big names that already support it such as amazon-cognito. You can also take a look at similar questions from this stack:

Password-less authentication in web apps - How safe it is?

Passwordless login over email - security considerations

As for your custom implementation there are several concerns worth mentioning:

Don't create users whenever there is no existing email-address. Endpoints and web forms are regularly spammed and you'll find your DB filled with junk.
There might not be a need to send a token in the email and instead just send a link directly. Just make sure that the link URL is generated randomly and that again the expiration is set to disable use.
As mentioned above emails can easily be compromised so you should set a shorter expiration to mitigate. In most cases your users will be accessing their email directly after anyway so I would keep it in the range of 5-10 minutes.
After login the JWT should also have an expiration even if it's a long one. You don't really want the tokens to be valid indefinitely.

To be honest I wouldn't recommend setting this up yourself if you can avoid it; Try to find libraries that already support this functionality.


Do mobile OS's provide crypto-quality randomness?

iOS on iPhone provides entropy from all standard inputs like accelerometers, compass, radio baseband, as well as from certain parts of the circuitry which picks up interference at all levels. Random bits are available to app developers via the SecRandomCopyBytes() function.

I don't have info on other platforms.


Site allows both Partial and Complete password authentication; do they have my password in plain text?

In order to support "partial passwords", the bank must necessarily store either the plaintext password, or at least some values that would allow fast reconstruction of the complete password. It is easily seen in the following way: when the bank asks for, say, the 3rd, 4th and 8th letters of the password, then there are less than one million possibilities (assuming that the "letters" are printable characters). Yet the bank can somehow decide whether the three provided letters are the right ones or not. Therefore, whatever the bank stores is sufficient to run a brute force attack on the 3rd, 4th and 8th letters, and that attack will succeed in less than a million tries.

The bank may add layers of encryption and hashing and whatsnot, this won't change that raw fact. Whenever there is support for "partial passwords", then there is very sensitive storage on the server side. In that sense, support for partial passwords decreases security, instead of increasing it. (It can be argued that partial passwords increase security on the client side: shoulder surfers gain only a partial view of the password. Yet you must be aware that this is a trade-off: more client-side security for less server-side security.)

To support full-password authentication, the bank must store something which is sufficient to verify a full password. The same reasoning as above applies, but for a brute force attack on the complete password, not on a partial password. If a bank supports both "partial passwords" and "full password" authentications, then it probably stores one of the following:

The full password in a "recoverable" format (plaintext, or encrypted with a key that the server knows -- that encryption being protection mostly against casual attackers on the bank side, e.g. underpaid interns).
A hash of the full password and hashes for all password subsets that the bank may ask to the connecting user.

The second possibility requires a lot more storage and implementation complexity on the bank side, so I deem it improbable. Developers of bank applications are no less lazy than their fellow humans.

Take note that your password is not your most sensitive asset entrusted to the bank. The bank holds your money. And the money is what the attackers are after. If an attacker completely hijacks the authentication server, he won't limit himself to grabbing encrypted or hashed passwords; he will immediately fake some successful authentication and trigger transfers. Who needs a key for a door when he is already inside ?

Discussions about encrypted or hashed passwords are relevant for partial breaches, e.g. when the attacker finds a backup tape for a database, or obtains a read-only view through some SQL injection attack. In that sort of scenario, what can be done by an attacker depends a lot on the subtle details of how things are implemented in the server, so it is hard to talk in all generality.


See this question for details. Roughly speaking, when iterating a hash function in a space of size N, then, after an average of roughly sqrt(N) steps, you enter a cycle whose length is of size roughly sqrt(N). With a, say, 160-bit hash function (e.g. SHA-1), both sizes will be about 280, i.e. way too large for problems to actually occur.


It is not unusual for cloud providers to have a system in place where they can access their customer's data, because there are all sorts of useful things they can't do without looking at the data. They can't index it, they can't de-duplicate it, they can't compress it, they can't scan it for illegal content, and most important of all, they can't restore it to the user when they forget their password.

That last option is most likely enough on it's own to make encryption a bad security choice for a consumer cloud system.

Note also that there are plenty of security controls that Microsoft can implement to stop some random contractor poking through the data.

Lastly, since Microsoft wrote the client software for the service (and most likely wrote the operating system your friend is using!) then if they are malicious they've already won.

There are alternatives if your friend is still concerned. There are small, specialist cloud providers who do encrypt the data at rest and cannot see it. It is also quite possible to build your own private cloud system. However, both these approaches raise additional questions and issues of their own.

What I would recommend, and what I use myself, is to encrypt any sensitive data locally before uploading it to the cloud.


A mobile phone, generally speaking (*), is broadcasting the message "the SIM card I have with the ID XXXX is now available on the network". This ID is called IMEI IMSI (**) and is unique to a SIM card.

The IMSI is then mapped to a phone number by your provider.

If you break this chain (by going to the network provider and requesting a new SIM card) the cloned card is useless: its IMSI stops to be associated with your phone number (which you may still keep on the new SIM card).

The technical corner: cloning a card into a functioning one is not a simple task (particularly if the card is protected by a PIN). It requires rogue cooperation with the network operator but once such a card is available, it is placed in a SIM-dialer - a device which continuously dials premium (expensive) numbers so that you run out of credit. This is why it is important to have it blocked as soon as possible, especially when you are in a foreign country. Fun fact: this SIM dialer is called in French a "pondeuse", which refers to a hen laying eggs.

That was for the "someone could call on my behalf" part.

You also mention that you are now getting calls from unknown numbers. These calls are not a danger, they are just particularly annoying. You can try to add them to your automatic rejection list and if they persist, then the only way is to change your number (which can be done without changing the SIM card, per above).

The shop may have given your number to scammers, you will never know. Or it may just be a coincidence.

As a side note, beware of calls which just ring once or twice, trying to get you to call back (or if you pick the phone up, there is a generic message like "I cannot hear you, hello? hello? Please call back this is important"). There are usually two categories of such scam calls:

the ones which show a local number. If you call that number you get a message of the type "you have received a voice mail, please dial  to retrieve it"
the ones which show a premium number with the international prefix for your country. The idea is that when you live for instance in France (prefix +33) you may be less reluctant to call back +33899235467 than an well-advertised 0 899 ... which is more recognizable as an expensive (premium) number.

(*) "generally speaking" means that what follows is mostly correct, there are many simplifications and some inaccuracies but you should get the whole picture.

(**) I initially wrote by mistake "IMEI" instead of IMSI. The IMEI is another identifier, unique unique to the phone itself (not the SIM). Its uniqueness is supposed to help to blacklist a stolen phone but it usually does not work (either the blacklisting is not applied by the carrier, or is reset by the thieves to something else).


What are my options for a career switch into IT Security?

Well.. if there is an area of IT security in which your skills would have any use that is pentesting. As software/web developer you know how a program/web works, so you should know which parameter, form, etc may be exploited. Also with programming experience you can go further and analyze the code from its source, not just trying the common attacks in websites.

All said was regarding to web pentesting. After learn about this (I recommend you The Web Application Hacker's Handbook -Finding and Exploiting Security Flaws and wargames), you should move into services vulnerabilities (here is where port scanners and frameworks like Metasploit get into the game).

Also with programming experience you could get into forensics.

Lately people trend to relate IT security with hacking and cyber war, and that's not true. I'm telling you this because I've read lately people who want to move into security because due to recent news they think this is like a "Hollywood Movie". If you are in this group of people, just keep programming, you won't success in security and you won't feel comfortable with your job.

About certifications, I think everyone should have the Security+ because it covers the basics about security. After... well when you have a Security+ you'll know how to approach your career.


Is SQL injection still a bad thing if the user is restricted to non-harmful queries?

Is it bad if the app is vulnerable to SQL injection if it does not cause any harm - yes. Is it critical - probably not. Should it be fixed - yes.

Basically you are having a multilayered defense: the first layer is to make sure to not allow SQL injection while the second is to make sure (using database permission) that a successful injection does not cause harm. The idea behind a multilayered defense is that any of the layers might not be perfect but combined they provide a better defense than alone. Just hoping that the second layer will catch any problems expects that this defense layer is perfect - which it often isn't.


cross-signed end-entity certificates: usage in apache/openssl/gnutls

openssl s_server -cert -dcert is only useful if the certs (and matching keys -key -dkey) are different algorithms. Then it will use e.g. the RSA key&cert for plain-RSA or DHE-RSA key exchange but the DSS key&cert for DHE-DSS. And similarly for ECDSA and ECDHE-ECDSA now that ECC is supported (since 1.0.0 except for RedHat).

Apache appears to be the same. http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile says

  This directive can be used multiple times (referencing different filenames) to support multiple algorithms for server authentication - typically RSA, DSA, and ECC. ...

and #sslcertificatekeyfile says

  The directive can be used multiple times (referencing different filenames) to support multiple algorithms for server authentication. For each SSLCertificateKeyFile directive, there must be a matching SSLCertificateFile directive.

This would only help if you can get your clients to enable/disable different keyexchanges based on which CA they want you to use, which is probably harder and more confusing than using different hostnames.

There actually is a standard extension defined for TLS1.0 by 3546 TLS1.1 by 4366 TLS1.2 by 6066 for the client to identify which CAs it trusts, and would like the server to use. But most extensions are optional and as far as I have seen no browser (or client at all) implements this one.


Analyzing log files for forensics homework?

My solution would be:

The user innocent compiles THC-Hydra from source, then realises that he / she is missing a necessery lib and installs it (hence the sudo aptitude install libssh-2 on innocent-laptop). He / she then proceeds to use Hydra against naive's ssh roughly at 18:22:30 (as marked by the network configuration). The attack succeds at 18:50:29. Innocent then proceeds to delete naive's .bash_history, launch a firefox on naive's computer (presumably through X tunneling) and sends an e-mail from naive's gmail to his / her own requesting a meeting at 5:50pm. Then innocent shuts down naive's computer and deletes his / her bash history before shutting down innocent-laptop too.

This basically means that innocent is trying to craft an allibi for him- or herself, which basically makes him / her the prime culprit in the murder.

TL;DR
Innocent isn't really innocent.

By the way where do you get homework like this? Because this stuff is awesome.


Is there a way to check later if a saved page originally served via HTTPS is legitimate?

There is no technical way you can know that the page is authentic other than having to reload it, i.e contacting the server again and validating its certificate. And that's by design, because otherwise it would kill the purpose.

Think about it, if there was such a way then it would be easy to copy another page's "authenticity" and apply it to fraudulent pages.


Difference between interception, spoofing, falsification and repudiation

Here is a rundown on the example of emails:

  Interception or Snooping or Sniffing

An attacker intercepts the unencrypted traffic of an email server to record and modify the content of sent and received emails. (Your ISP, router or network administrator are all able to sniff/intercept the unencrypted traffic that they process.)

  Spoofing

An attacker crafts an email with a forged sender address to appear as if it comes from your boss and asks you for a password. This is aptly called email spoofing.

  Falsification and

Falsification refers to spoofing. In a spoofing attack you falsify ("forge") data.

  Repudiation

An attacker gains access to your mail account and sends rude messages to your boss. You probably can't repudiate (deny) having sent these messages easily because the system doesn't keep track of the IPs that logged in to your account.

You might want to have a look at STRIDE, one of the most common models to classify security threats. It distinguishes Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege. This classification might be a little more thorough than your proposed list.

Microsoft has a good overview on threats and countermeasures that includes STRIDE.


Yes. But on the other hand you don't want the log file to potentially contain the passwords, which would happen if someone botched the login and sent the password instead of the username.

What I think might be a viable compromise could be to log:

attempts with valid usernames and invalid passwords, logging the username but not the password.
attempts with invalid usernames (which might be passwords or whatever), logging the username as "INVALID".

The rationale is that several attempts with a single valid username will tell you of a possible bruteforcing against that username; a swarm of attempts against the INVALID username will warn of a large-scale "username with obvious password" attack, which, if you have a proper password policy, is irritating but harmless. Even more so the attempts against well-known users.

It is conceivable that someone might be attempting to bruteforce a single invalid username; if that's a concern, you might log invalid usernames as (partial and/or salted) hashes. The value of this cleartext information, even if captured by hostile parties, would be essentially nil.

A very small number of attempts on the INVALID username may be due to users misspelling their own names, or entering the password instead of the name; or paranoids that intentionally botch their first login believing this to protect against credential capture.

Especially if quickly followed by a valid login from the same address (unless it's a system masquerading a large network...), an occasional authentication error of this kind could be considered noise and ignored.

(You might further distinguish a small set of "valid invalid names" such as info, admin*, Administrator, guest, if you wanted, but that's probably overkill).

Also, for the truly paranoid, you could pad all valid usernames and the string "INVALID" to be the same, fixed length (say... 20 characters?). If by any chance an attacker could be able to remotely observe the log file's growth, he would thus be unable to tell whether a username was existing or not on the system.


Difference between private key exposure and tampering in mutual authentication

The most obvious difference between them is that in Scenario A, the attacker can carry out Man in the Middle attacks with very little chances of getting caught, since the key pairs remain unchanged and there is almost nothing out of the normal for either parties to notice.
In Scenario B, the attacker changes the key pair. Although, in some cases, the attacker can still carry out a successful Man in the Middle attack, this has a significantly higher chance of getting caught since any of the parties can notice the sudden change of the public/private keys if they have already communicated in the past with uncompromised keys (specially if the client implements something like public key/certificate pinning).


redirect as @Terry mentioned is ok, but will not work if users use bookmarks and you want to make them available also in HTTPS:

dont forget to use HSTS-Headers
Solution using .htaccess only (untested) (see apache-wiki)

you can skip the %{HTTP_HOST} - condition if you use a
<virtualhost> - config for each virtual host
and no catchall/regex-servernames

--- first solution
RewriteCond %{HTTP_HOST} sub\.abc\.com
RewriteCond %{HTTPS} !=on
RewriteRule ^/(.*)$ https://sub.abc.com/$1 [r=301,L]

--- 2nd solution
RewriteCond %{HTTP_HOST} sub\.abc\.com
RewriteCond %{SERVER_PORT} ^443
RewriteRule ^/(.*)$ https://sub.abc.com/$1 [r=301,L]

Solution using Rewrite-Rule and with working deep links / server-config (prefered by official docs):

<virtualhost :80>
    ServerName sub.abcd.com
    RewriteRule ^/(.*) https://sub.abcd.com/$1     [R=301,L]

</virtualhost>

<virtualhost :443>
     ServerName sub.abcd.com
     Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</virtualhost>


I want to encrypt certain entries in a database. Is this a good plan?

Given that you say this is not a real application, I'll only comment on a couple of points here. The first is an implementation detail that you might have already considered, the second is more of a theoretical "is this worth while?" question.

1. Password changes.

It is generally considered good practice to require users to change their password every so often. If this password has been directly used to derive the key used to protect their data, then you're going to have a world of hurt ahead of you: you'll have to decrypt their stored data with the old key and then encrypt it with the new key. Yuck. Wasted machine cycles and a potential honey-pot for an attacker, since you have to go back to the plaintext to do this.

A better scheme would be to allocate the user a random key (their Data Encrypting Key or DEK) when they sign up, and encrypt that key with a key derived from their password (their Key Encrypting Key, or KEK). The DEK is used to encrypt the actual data, the KEK is used to protect the DEK, and is never stored. Then, when they change their password, they are just changing the KEK: the DEK does not change, and so the stored data does not need to be updated, other than the encrypted value of the DEK, which is now encrypted with the new KEK.

2. Is this a good idea?

Yes. Absolutely. Encrypting the actual data in a database protects the data against some threat vectors that less granular approaches don't cover. For example, neither an encrypted file system for storing the database tables nor database table encryption protects against a rogue database administrator with the ability to issue a select * from customers; query. If the data itself is protected and the keys are secure (an important consideration), all an attacker can get is the encrypted data.

That said, there are some issues to consider. For example, if you encrypt customers' SSNs in your database, will that impact your call center employees who routinely ask customers for their SSN in order to authenticate them? Plus, what happens when data from your system has to be exported in order to be sent to a business partner, who doesn't have access to your keys?

None of these issues are reasons not to implement security in your applications, but you should be aware that this is not a trivial undertaking.


How to deliver an encrypted message to multiple recipients without revealing keys

I think you've gotten public key cryptography all out of whack, here.

You don't give out a private key. Period. They're called "private" for a reason.
You don't send an encrypted message along the same channel, let alone at the same time, as you send the only key that is needed to decrypt it. That completely defeats the purpose of the encryption in the first place.
A key pair is only useful for authentication (i.e.: digital signature) if the public key has been verified by the recipient(s) (or a trusted third-party) prior to use.

So, how do you deliver an encrypted & signed message to multiple parties without allowing them to impersonate you in return? The answer lies back in #1: No two people hold the same private key.

If you're the only one with a copy of your private signing key, nobody can impersonate you. You simply sign the message with your private signing key before any encryption is done. Recipients then use your public signing key to verify the message's authenticity after they've decrypted it.

The encryption portion is a completely different matter. And for that, you have a few options.

No encryption. Just sign and deliver. Authenticity is protected regardless, but this method offers no confidentiality.
Encrypt with pre-shared key (PSK). Emphasis on pre-shared - this one doesn't get shipped along with the message. It should be shared among the group before-hand, preferably out-of-band. The PSK is used for encryption/decryption only. Your signing key is what provides authenticity.
Encrypt individually with public keys. Take the signed message, and make a copy for each recipient. Then, encrypt each copy with one recipient's public key and send it along. The recipients will use their private keys to decrypt the message.
Use private keys as key-encryption-keys (KEK) for a shared key. Depending on the size of the message, this can be quicker than #3 while still keeping the benefits of public key encryption. You generate a random, one-time use, shared key. Use that to encrypt the signed message. Make a copy of the shared key for each recipient. Encrypt each copy of the key with one recipient's public key. Bundle all the encrypted keys together with the encrypted message and send a copy of that same bundle to each recipient. Each recipient will use their private key to attempt decryption of each copy of the shared key until they find their copy, then they'll use that to decrypt the message.

Again, the main thing that protects the authenticity & verifiable origin of the message here is the fact that only you have a copy of the private key that was used to sign it. Beyond that, for authentication purposes only, it doesn't matter how or even if the message is actually encrypted. At the end of each of these processes, when the recipients have a cleartext copy of the signed message, your public signing key is what they'll use to verify its origin and integrity.


The standard way of handling this is through segregation of duties.

Basically, it means that you have a team that handles deployment that is completely separate from the team that handles deployment in production and that you have a separate team that perform auditing.

Also, proper encryption of the database and key handling will help limit access to sensitive data: people who have access to the database servers (DBAs) usually are not granted access to the decryption keys while people having access to these decryption keys (typically the security team although it could also be the system administrators) are not granted access to the databases.

The devs, who usually needs to have access to both set of data for development and testing, are never granted access to production, only dev and pre-production systems.


What TCP-level commands affect the global configuration of the stack?

TCP fingerprinting doesn't really help you identify a client.

When we talk about TCP fingerprinting, we're talking about the configuration details that, taken together, help identify the habitual configuration of an OS.  Different OSes have different default TTL values, for example.

You're asking about identifying non-habitual (unique) aspects of TCP traffic from a given host, but these details rarely vary from one installation of that OS to another.  If 100 visitors to your web site are running Windows 7, then those 100 visitors will share TCP characteristics that are essentially indistinguishable from each other.  For this reason TCP fingerprinting is used to identify a generic aspect (the OS) of a single system, not identifying aspects of multiple systems.

(The exception is actually TTL - if a remote machine is trying to spoof IP addresses, their traffic may be distinct by the TTL of packets as they arrive, because they all start with the same default TTL and they generally will decrement by the same amount as they follow the same network path to you).


How can I encrypt a file using gpg without including the recipient's key ID?

Use the -R (or --hidden-recipient) flag in gpg to do this. More details in this answer.


How to MiTM SSL on a device with no proxy settings

I believe there must be some sort of confusion here. You seem to think that Fiddler is some attack/hack/magical tool. To decrypt SSL traffic with Fiddler you either need to possess the session key or you need to install Fiddler's certificate on the device.

Asking for an attack vector and talking about using Fiddler in the same question sounds silly. You're saying you already have access to the traffic, you're already an MiTM. All you need to do is use the session key and or get the device to trust your fake certificate.

I highly recommend that you read up on the topic.


Difference/Relationship between data leakage analysis and vulnerability analysis?

"Data Leakage" is typically defined as unauthorized data that becomes available due to the actions of the normal operation of the program/user. As for your example of data transmitted unencrypted, I would see that as not a a vulnerability analysis but a normal part of a data analysis (any place the data touches requires appropriate protections for the classification of that data).

The relationship, then, to "vulnerabilities" has to do with information that can be extracted if a user exploits a weakness in the program.

The difference is normal operation vs unexpected operation.

As for how much Vulnerability Analysis might be required, it depends on the scope and expectation of the report. If you are tasked with defining the impact of normal operations ("operational focus"), then you do not need to do any vulnerability testing. If, on the other hand, the report is supposed to define each and every threat the to data ("data focus)", then you need to perform very detailed analysis of not only the potential vulnerabilities, but also a deep dive into an analysis of the code and architecture itself.


LUKS, how to make strongest possible and reasonable passphrase?

In the context of security, everything is a trade off.  More on that in a second....

What are the attack options for breaking into your encrypted volume?   They are, basically:

Brute force search of the keyspace for the key utilized by the symmetric encryption primitive.
Brute force the passphrase by trying every possible password utilizing your volume's specific salt and key derivation parameters.
Evil maid, rubber hose, key logger, or other "non crypto" means of securing your keymat.

You should worry about number 3.  Because its the obvious attack vector.

No one is going to succeed in brute forcing the key used for the block encryption primitive.

From a basic security perspective, I remain convinced that even 128 bit keys are fully secure if the implementation is not broken.  A brute force search in that case has to exhaust on average half of a key space that has 340,282,366,920,938,463,463,374,607,431,768,211,456 possibilities.

For a 256 bit keyed primitive, you're talking about 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 possibilities.

So even with 256 bits of key security you're already reaching numbers that approach the number of atoms in the known universe.

So that's out.

What you're worried about is someone trying every possible pass phrase.

Now, remember that LUKS uses some salt + PBKDF2 to stretch your pass phrase to the size of the key space.   What this means is that even a password of "a" can map to any possible spot in the entire key space.  So attackers aren't going to have a rainbow table that will help here.

If they're going to brute force the pass phrase, they will have try all the possible inputs, running each through the key derivation function with the parameters used on your volume (salt & iterations).  That takes time.  And, if memory serves, LUKS actually sets the iterations to take a specific amount of time per "try."

What this means is that you simply need a pass phrase length that has enough entropy to make it unfeasible for an attacker to try a sufficient number of possible phrases to locate your phrase.   The attacker can of course use GPUs or specialized ASIC hardware to speed this process up (its why folks are experimenting with things like Scrypt to make that harder), but you will be more than protected with 20 to 30 characters containing lowercase, uppercase, numbers and keyboard symbols (including symbols from shifted numbers and other symbols on the keyboard).

This brings me back to my initial comment.   Its important to keep in mind the trade offs.  You can try to come up with a pass phrase that is equivalent to the difficulty of your 512 bit key space, but it will IMPACT your behavior.   You might find yourself not dismounting / logging off when you get up to get a cup of coffee because its such a pain to get that pass phrase right when its time to log back in.  You might store the long pass phrase on a phone or piece of paper.   If you store it in a password manager, you will be limited by the security of the password manager and not the security of the length of your pass phrase.

Meanwhile, once an attacker has to try 20 to 30 characters of pass phrase utilizing 93 possible characters, the attacker is facing (effectively) 95 to 150 bits of entropy which puts it outside of the reasonable range of brute force.

And, all of which leads back to that third possibility of getting into your volume.  Compared to brute forcing the key to the encryption primitive or trying all the possible pass phrases, the third scenario "COMPROMISE" is really what you should be worrying about.   An attacker that gets you to point a compromised web browser at an exploit that gives escalated privileges on your running system can scan the memory for your password.   An attacker that gets a rootkit on your system can do the same.   If you plug in a compromised USB or firewire device, you're potentially compromising security.   And these are all much easier for the attacker than brute forcing the keyspace or pass phrase space.


I searched for "what is client-channel.google"

And got this as one of the top 3 hits: https://support.google.com/a/answer/2589954?hl=en

  In order for users on your network to access Google Drive and Google
  Docs editors, your firewall rules should connect to the following
  hosts and ports. Otherwise, users may be blocked or denied access from
  these services.

  ...

  [N].client-channel.google.com:443/HTTPS

My assumption is that you captured those URLs while using Chrome to connect to your dummy web application and caught traffic from Chrome to Google.


How to check if Android application is vulnerable to heartbleed

Heartbleed is primarily a server-side vulnerability and not in the client. You, of course, cannot detect the server-side problem from examining the client-side code. Even if the client has very old SSL code, you don't know what the server is running.

You can test the server for heartbleed at https://filippo.io/Heartbleed/.

Heartbleed on the client will occur if the client is using a pre-fixed version of OpenSSL. The client vulnerability could only be exploited by a server that the client has contacted. That is, a server cannot find your client by snooping the network or anything of the sort. The client must initiate the contact.

A successful exploit will allow the server to read the process memory of the client. (Reading memory with Heartbleed is tricky and it may not be possible to read all of the process's memory, but let's ignore that.)

(Thanks to @StackzOfZtuff for helping with this edit)


2FA: Do app passwords render the second factor invalid?

Another point: people who type a password usually have it remembered and will surely use it on another service - password reuse. In this cases, no matter how long and strong your password is, it is as secure as the least secure service you use the same password.

So if you have a random 128-byte password, but use it on 3 services, and one of them stores it on plaintext (and it happens more than you think), it only takes one leak to your unbreakable password to be left on the wild. And there goes your security.

To protect on those cases, you have the 2FA. It protects the password on every service you activated it, but protects the third party services sharing the same password. Even if the attacker manages to grab both the password and the 2FA token on, say, orange.com, and you use the same password on pear.com, I can bet the 2FA tokens will differ, and the attacker will not be able to log in at pear.com with your password.

Application passwords solves some problems:

No password reuse. Every application will have its own secure, long and unique password.
Less chance to a keylogger grab it. They are usually set-and-forget, and most of the time it gets displayed only once, and if you forget to copy it, you must generate another one. As they are long, you will copy and paste, not type.
Less change to fall for phishing. User will most of the time go to the service they want to connect, generate a password, go to the application, and configure the password. It's very rare to see a phishing site asking for the user to setup an application password.
Easy to revoke. One application is misbehaving? You suspect something is wrong with one application? You don't want to use a service anymore? Easy: revoke its password. No need to change the main password, and change it on every single connected service.

As the threat models for user entered password and protocol-used password are different, you need a different protection. That's why an app password is secure, even without 2FA.


Running open relay smtp in company network

Open relays = bad. Anything that can access the relay can send out emails using your domain. Closing relays, like not choosing "password1" as your password is a basic protection.

Only use an open relay if you have other mitigating controls that prevent other nodes from accessing it. Authentication is the easiest way to do this.

But, if you can control network access, there can be ways to create a pseudo-open relay (no auth on the relay, but access controls on other layers). In the past I have used VLANs, NAC, switch port configuration, IP whitelists, etc. with added monitoring and alerting for anomalies. Not the best option, but a risk-based approach if it's the only way forward.


Django SECRET_KEY security, how are methods more secure

Once an attacker already has access to the system it's already way too late. The main concern  for not leaking the key is because it is often used as a seed for hashing and signing sessions.  The idea is that your production SECRET_KEY needs to be completely different than your development or staging SECRET_KEY. You can actually randomly generate it every restart although this might impact user experience (see details below).

As long as you adhere to the principle of changing the key there is not much danger if you commit or not (as long as you ensure it is changed once going from dev to prod). If you don't, then someone having the key can predict the outcome of hashing algorithms (used for sessions) or even sign sessions.

If an attacker has gained access to your system you're already too far gone because it's not your system anymore. One thing you do need to ensure is that the file permissions on your settings file is only readable by the user running the webserver and by no-one else. This prevents someone who illegitemately gained access to a limited account, which is not the same as the webserver account, from compromising your key.

There is a good answer here on Stack Overflow: Django SECRET_KEY written by sberder which details what it is used for:

  JSON object signing
  crypto functions for salted hmacs or seeding the random engine which impacts:

  password reset token
  comment form security to protect against forged POST requests
  form security
  protect against message tampering as the message framework may use cookies to pass messages between views.
  protect session data and create random session keys to avoid tampering as well.
  create random salt for most password hashers
  create random passwords if necessary
  create itself when using startproject
  create CSRF key

  In reality a lot of the items listed here use SECRET_KEY through django.utils.crypt.get_random_string() which uses it to seed the random engine. This won't be impacted by a change in value of SECRET_KEY.

  User experience directly impacted by a change of value are:

  sessions, the data decode will break, that is valid for any session backend (cookies, database, file based or cache).
  password reset token already sent won't work, users will have to ask a new one.
  comments form (if using django.contrib.comments) will not validate if it was requested before the value change and submitted after the value change. I think this is very minor but might be confusing for the user.
  messages (from django.contrib.messages) won't validate server-side in the same timing conditions as for comments form.


There is no theoretical reason why asymmetric algorithms can't be optimized to handle larger length plain text messages, but symmetric algorithms have a few advantages for application level data bound to their symmetric nature.

Having a single secret shared between two peers for user (application level) messaging is conducive to simple and elegant protocols.
Less cryptographic innovation is required to provide speed and resistance to partial plain text and other attacks because the burden of having a public key that does not open a door to the discovery of the private key in any reasonable time frame is relieved.
Symmetric algorithms and software implementations of them have evolved over the historical use of SSL and TLS along the lines of high speed, stream-able frame handling, and resilience to attack for large messages.


Are timing attacks for PHP used in practice?

If the timing difference is in plaintext password comparison, it is not really feasible to do this over the Internet. However, it is often possible for the attacker to get access to a computer in the same network, or even to a VM on the same hardware, by hosting his attack with the same hosting provider as the target web site.

If the site uses hashed passwords and compares the hashes instead of the plaintext password, this timing attack scenario doesn't apply anymore.


Putting an xinetd server in front of your web server will reduce security: in addition to any security holes in the web server, you now also are vulnerable to any security holes in xinetd.  Any security measures you can apply through xinetd, you can apply instead through the firewall or the web server.


Can you protect against SQLi without using prepared statements?

Not sure what escapeSimple does exactly, but if it behaves like mysqli_real_escape_string then it's ok, as long as you are not using some weird character encoding or forget to set it correctly (UTF8 should be ok by default, as far as I know).
Remember that using MD5 or any other simple hashing function is considered bad practice today, and you should use better functions which take more resources to compute (and with salts), for example bcrypt, argon2, etc.
I also don't like that == in the comparison, you should always use === unless you have a good reason to want type juggling. Otherwise you are going to get into trouble and something like this might happen: https://stackoverflow.com/questions/22140204/why-md5240610708-is-equal-to-md5qnkcdzo
By the way, there might also be timing attacks to consider (see Alexander O'Mara's comment below).
That said, your question was about avoiding SQL injection without prepared statements. Yes, it's definitely possible to avoid it, if you are very careful and make sure every statement is correctly constructed and its parts correctly escaped. However in some cases it might be tricky, and to avoid any mistakes of course prepared statements are the way to go.


Secure WebSockets (wss://) properly protect the data during transfer, same as HTTPS does. But outside of this the application logic might introduce enough problems to impact the security of the data, similar to just using HTTPS instead of HTTP does not magically make the application safe against things like XSS, CSRF, SQL injection... . On top of this WebSockets don't rely on the Same Origin Policy (SOP) and thus attacks like Cross-Site WebSocket Hijacking are possible unless the server side properly checks the Origin of the connection.

  Is it secure enough for extremely sensitive information like used in banks?

If properly used it is safe for sensitive data. I have no idea what you exactly mean with extremely sensitive but if these data are really extremely sensitive I would not rely on a single layer of protection in the first place.


The best thing you can do is to make a script that makes the HTTP requests and check the responses, I will suggest you to have a look to the python module requests or even pycurl and choose the best suites you.


As an alternative (or in addition) to completely disabling your command history, you could mount your encrypted volumes interactively. I haven't tried this myself, but the manpage tells us the -i option requests all security-sensitive information interactively from the user (so it doesn't get logged in your history file).

Of course as already indicated by others, if an "attacker" were to install a keylogger or such onto your system, none of these methods will work.


What are WiFi certificates used for? What are they?

Increasingly, wifi access points (or the portals which serve as "sign in" pages for visitors and guests) feature support for SSL certificates.  These certificates are designed to serve a dual purpose:

1)  Validation: They provide cryptographically-backed assurance to the visitor that the device they're connecting to genuinely belongs to the organization they think they're connecting with.

2)  Encryption: They serve to encrypt the connection between the client device and the server/host end (in this case, the wifi hosting device).

Just about every web browser comes pre-installed with dozens.. even hundreds of identity certificates that belong to Public (or External) Certificate Authorities (CA's) such as Verisign, Comodo, Digicert, etc.  This is done mostly out of convenience so that when you connect to a site whose certificate is signed by one of these vendors, 99% of the general public will have their browsers recognize them as legitimate.

However, most large private organizations at some point will want to deploy their own PKI for greater control and cost-savings.  So they'll implement their own Certificate Authority.  Then they'll configure the Microsoft network to push that internal CA's certificate onto all the organization's client devices' Trust Stores.  So now in addition to Digicert, Comodo, Verisign, that laptop or mobile device will now trust certificates signed by that internal CA.

That last step is crucial. If this is not done, visitors will see ugly error messages warning that the Certificate's Not Trusted, or something like that. The certificate will still provide visitors with encryption, sure, but zero validation benefit. It's possible the university has deployed its own internal PKI, pushed certificates to its employee devices, and left students to scratch their heads, wondering, why is my web browser or client software throwing up errors when I try to connect?  And that would make sense, especially since the University doesn't control your machine.

It's likely because the University is using an internal PKI, and your device doesn't have their CA's certificate installed in your Certificate Trust Store. To solve this, just ensure that the certificate you're being presented with is authentic (you could call the service desk and confirm the certificate's fingerprint, if you know how to look for that--if not, look in the certificate details).  Once you're certain, download the Root or Intermediate certificate and install that into your Trusted Root Store.  You may have to restart your browser.  Once that's done, however, you shouldn't see those errors anymore.

Here's a good article to reference:
https://technet.microsoft.com/en-us/library/cc754841.aspx


Can someone know who created a cpp file?

No. Plain text files only include the plain text, and no further metadata. Only the file system records metadata about the file, and as you've seen, it can be easily forged.
However, further analysis of the file system or related systems may yield useful information. For example, if the file is stored on a network drive, it may be possible to look at log files, e.g. if Windows' “auditing” feature was enabled for the shared folder. It may also be possible for a forensic analysis to view old versions of file metadata when a journaling file system such as NTFS is used.
But all of these approaches only relate to metadata on one file system. Only file contents (not metadata) are copied when a file is copied from another file system, e.g. when a file is copied from a thumb drive.


nmap scan shows ports are filtered but nessus scan shows no result

Unless you've got nmap configured not to perform host discovery (-PN or -PN --send-ip on the LAN), if it is indicating that all ports are filtered, then the host is up, but the firewall on that host is dropping traffic to all the scanned ports.

Note that a default nmap scan does not probe all ports. It only scans 1000 TCP ports. If you want to check for any services, you'll want to check all 65535 TCP ports and all 65535 UDP ports.

Also, to be precise, but when the port scan says a port is filtered, that doesn't mean that there is no service running on that port. It's possible that the host's firewall has rules that are denying access to the IP from which you're running the scan, but there may be other IPs which are allowed to access that service.

If the port scan reports that a port is closed, that's more definitive that there's no service listening on that port.

I can't comment on the lack of results from nessus, it's been a while since I've used it.

Example of closed vs. filtered vs. host-down

E.g., on my network, this host is up, has no services running, and does not have a firewall, note that the ports are reported as closed (this means the host responded to probes on that port):

% sudo nmap -T4 -n 192.168.1.24

Starting Nmap 5.00 ( http://nmap.org ) at 2011-11-30 11:20 EST
All 1000 scanned ports on 192.168.1.24 are closed
MAC Address: 00:0E:00:AB:CD:EF (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 7.70 seconds

This host is up, has no services running on ports 100-1000, and has a firewall. Note that the ports are reported as filtered (this means that the host dropped probes to those ports):

% sudo nmap -T4 -n -p 100-1000 192.168.1.45

Starting Nmap 5.00 ( http://nmap.org ) at 2011-11-30 11:24 EST
All 901 scanned ports on 192.168.1.45 are filtered
MAC Address: 00:12:34:AA:BB:CC (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 20.03 seconds

Just for illustration, I punched a temporary hole in the firewall for that last host for port 443 and reran the scan. (There's nothing running on 443 there.) Notice how 998 ports are reported filtered, but port 443 is reported as closed; the firewall is allowing 443 through, and the OS responds with an RST.

% sudo nmap -T4 -n 192.168.1.45

Starting Nmap 5.00 ( http://nmap.org ) at 2011-11-30 11:43 EST
Interesting ports on 192.168.1.45:
Not shown: 998 filtered ports
PORT    STATE  SERVICE
22/tcp  open   ssh
443/tcp closed https
MAC Address: 00:12:34:AA:BB:CC (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 5.67 seconds

There is no host at this address (host down):

% sudo nmap -T4 -n 192.168.1.199

Starting Nmap 5.00 ( http://nmap.org ) at 2011-11-30 11:26 EST
Note: Host seems down. If it is really up, but blocking our ping probes, try -PN
Nmap done: 1 IP address (0 hosts up) scanned in 0.56 seconds

if I rescan with -PN --send-ip (the latter is needed because I'm scanning the LAN, and I don't want to use ARP probes), I see:

% sudo nmap -T4 -n -PN --send-ip 192.168.1.199

Starting Nmap 5.00 ( http://nmap.org ) at 2011-11-30 11:29 EST
All 1000 scanned ports on 192.168.1.199 are filtered

Nmap done: 1 IP address (1 host up) scanned in 101.44 seconds


Looking at it from a security point, I wouldn't recommend it. You're giving someone else the rights of your e-mail, they are basically you from that point.

And just like @AstroDan said they are gathering information about your buying habits. It makes it easier for you, but someone else is making much more money of it.


The sandbox restricts each application so that it can only read its own files, and must get explicit user permission for access to features like location, camera, microphone, etc. Cookies are stored per-app, and sqlite databases are files subject to the sandbox restrictions.

On any phone, jailbroken or not, some of the Apple apps are system apps which are not restricted by the sandbox.

On a jailbroken phone the sandbox is still enforced for standard apps. However, it becomes possible to create third-party system apps that are not restricted by the sandbox. The details vary depending on which jailbreak you use. There's good information here: https://stackoverflow.com/questions/16026920/why-sandbox-in-ios-6-1-1-still-exists-for-app-even-after-i-have-jailbreak


How much does it cost to protect your website against DDOS, by tier?

Protection against DDOS is, on a general basis, pretty much impossible. Normal operation of a server is to handle clients, doing some computation when a request is received. A DDOS is... just that. The difference between the normal situation, and a DDOS, is that the "clients", in the latter case, are not interested in the result returned by the server, since the clients happen to be mindless zombies. "Being interested" is not a concept which lives in the abstract world of computation.

So the strategies for dealing with DDOS are a combination of:

Trying to detect zombies based on "usage patterns" (assuming that a zombie involved in a DDOS will behave in a way which is distinctively different from a "normal user" -- this involves quite a lot of faith in Mankind).
Having the clients invest some computational effort, such that the server can verify that work has been performed, with much less effort.

The first strategy is a psychological hide&seek between attackers and defenders, and we can expect roughly the same kind of success than for antispam -- i.e. good against amateur attackers, bad against determined attackers. The second strategy is an ongoing research subject but there is nothing widely deployed in existing software. That's one trouble with Web servers: they cannot ask for anything that existing Web browsers do not already know how to do.


Delete cookie or set httponly and secure

Login/session tokens or tokens that carry user data have to be Secure and HTTPOnly, or they become a security issue.

Explicitly hitting a logout button, rather than just token expiry, results in a "logout" request to the server. Have the server invalidate the authentication token (cookie) but setting it to some junk value. For example, Set-Cookie: token=loggedout.

Deleting a cookie may be a client side action, but setting a cookie can be done on the server side and you can still maintain HTTPOnly and Secure (which, as 8zero2.ops pointed out, is unrelated to this issue).


I was wondering, what would happen if a Tesla car was hacked into?

Nothing good I can promise you that.

  Are future cars designed to be able to be stopped by police via remote access and commands?

Not that we know of.

  What if someone actually causes an accident using this method? Who will be to blame? How can one prove the accident wouldn't be caused by the police or someone (connecting to say a SIM card embedded in the car)?

I will assume you will not be able to blame anyone until after an investigation is complete and there was evidence that either the car was hacked into or not.

Note:
Hackers have already proven they can hack into a Tesla car. See here.


How can I limit which key sizes and signature algorithm of the next certificate in the certificate chain are allowed?

These kinds of policies come from the Certificate Practise Statement of the CA signing a request and should not live in the fields of a CA certificate.

If you don't want e.g. < 3000 bit keys in child certs, the correct approach would be to refuse to sign a request that does not comply with minimums rather than expect the client to interperet a policy encoded in the CA's certificate.
In contrast, the signature algorithm and hash size are set by the CA when the signature is generated, so this is entirely down to the configuration of the signing process used.


You tagged this question as pgp and mention PGP in the question title, so I am assuming that this is what you are asking about.

PGP (PGP, OpenPGP, GnuPG) has supported encrypting a file asymmetrically to several recipient keys for like forever (certainly for the last decade; probably for far longer).

For command-line GnuPG, the simple way to do this is to give multiple --recipient (-r) command line arguments listing the different keys. Other implementations will have some other way of accomplishing the same result.

Each recipient share their public key and controls their own corresponding private key, so no private key sharing is involved.

Technically, this creates multiple public-key encrypted session key packets in the resulting ciphertext file, each encrypted with a different recipient public key. This typically requires a few tens of bytes per recipient key, so the overhead can be considered minimal unless the number of recipient keys is huge.


Yes any one can upload file with Malicious Code
to make remote code execution, stored XXS or OS injection
read this answer
MIME Type vs. Magic Numbers


There are three timestamps normally recorded:

mtime - updated when the file contents change. This is the
"default" file time in most cases.
ctime - updated when the file
or its metadata (owner, permissions) change
atime - updated when
the file is read

For your need you will need atime, so you can open your USB device in terminal:

user@ubuntu:/media/USB-2477$

and run: ls -l --time=atime myfile.pdf

This will return to you when was the last time when you accessed that file. For copying the file I'm not sure if that will be recorded.

Or use stat it has similar function:

 stat --printf="Change %z\nAccess %x\nModify %y\n" myfile.pdf

It will return:

Change 2017-09-27 21:06:23.000000000
Access 2017-09-27 22:04:00.000000000
Modify 2017-08-11 21:36:40.000000000


Is it possible to "deauth" wifi direct connections?

To send deauth packets first you need to bring your WiFi adapter in monitor mode.
I'm using DELL laptop (INSPIRON N5050) which supports monitor mode.

I've installed Kali Linux and below are the commands to send deauth packets to particular AP.

airmon-ng start wlan0
airodump-ng wlan0mon
airodump-ng -c 1 --bssid [target bssid] wlan0mon
aireplay-ng -0 0 -a [target bssid] wlan0mon

airmon-ng stop wlan0mon


Deterministic password generation using Yubikey

The first problem is, that if you loose the device with the nonce, you can't recover anyway. There is no point in having it be deterministic if you add non-deterministic nonce.

Second problem is, that they can login to the site by capturing the password anyway. Just slight modification to the keylogger. It is always the same. That is why challenge response is being used.

IMHO the best solution would be to use challenge response and add two yubikeys or other tokens, one for normal use and one as a backup in case the primary one is lost.


DNS Server Recursive Query Cache Poisoning Weakness "Bounce DoS"

Basically, the DNS Cache poisoning (also known as DNS spoofing) consists in:

An attacker attempts to insert a fake address record for an Internet domain into the DNS. If the server accepts the fake record, the cache is poisoned and subsequent requests for the address of the domain are answered with the address of a server controlled by the attacker. For as long as the fake entry is cached by the server (entries usually have a time to live (TTL) of a couple of hours) subscriber's browsers or email servers will automatically go to the address provided by the compromised DNS server.

Here is a link explaining it.

The more important the dns server that has been compromised, the greater number of requests will be received and the users of other DNS servers that use it as a forwarder will also be affected. That's the "bounce" you are talking about.

And to answer to your question how important is UDP?. Is as simple as UDP is the protocol used for DNS requests. TCP is only used for zone transfers. So every request is travelling as UDP. And as you know (I guess), UDP packets work in a similar way to TCP but they throw all the error-checking stuff out. All the back-and-forth communication and deliverability guarantees slow things down, so UDP usually is better to perform DoS because is faster.

Here is another interesting article. On this, it's explained very well how to use a DNS server to be part of a DDoS (Distributed Denial of Service) attack.


An open port is not a security vulnerability in itself. It allows an attacker to connect and exploit any vulnerabilities in the process that's running.

The answer to your question depends on how sure you are in security of your service. Did you ask someone to look at the code? Does it run with limited privileges (not root?). What's the worst that can happen if someone can control this service from the Internet?

Given answers to these questions ("risks"), you need to balance them with benefits from setting it up as you describe and see what you and your customers are comfortable with.


Partial answer to 1 and 2:

There are two servers involved in Google Cloud Messaging, the third party / app developer's server and Google's server. Data sent from the 3rd party server to the Google server is sent over HTTPS with the 3rd party's unique API key in the POST header, so done correctly this should provide authentication of the 3rd party server, integrity and replay protection, i.e. it should not be spoofable. This relies on both the third party and Google securely implementing their services.


Security concept for Android app with PHP based REST API

This proposed security system is vulnerable to CWE-602: Client-Side enforcement of server-side security, and does not limit an attacker's ability to access this RESTful API. Fundamentally,  any secret provided to the mobile app will be known by the attacker.  An attacker with a jail-broken phone can observe memory used by any running process.

It must be assumed that an attacker will have full access to your API.  Any functionality provided to the client is by definition attacker-accessible, and must undergo a security review. A good place to start is look for issues found on the OWASP top 10.


Are there any reasons to add a payload signature to a REST API with mutual TLS?

I suspect this will be a big "It depends on your architecture" and so random internet people won't be able to give you a complete answer.

Off the top of my head, here's some scenarios where it might make sense to have client-auth TLS and payload signatures. The first are network constraints:

The TLS is terminated by CloudFront and the app server / backend doesn't get to see the client cert.
You want the message retains its tamper-protection even while bouncing around the server back-end in plaintext.

Then there are a host of ways that you could have a logical separation between the TLS connection and the API requests:

There's one Server <-> Server TLS connection that is routing requests for all logged-in users.
The payload signature is tied to some sort of API key, maybe for licencing reasons.
Non-repudiation and auditing: users have non-repudiation keys which are kept at a higher security level than the TLS certs.


Using Two-Factor Authentication to Stop Pass-the-Hash

Matt Weeks, in his Credential Assessment Mapping Privilege Escalation at Scale talk, discusses many techniques to prevent PtH, PtT, and PtK (OPtH).

Starting at 41:50 and up until 48:52, he goes over many prevention angles and gotchas -- https://youtu.be/_XXs8pRnqSQ?t=41m50s

My favorite recommendations are the rotation of KRBTGT weekly, and, if you can utilize smart cards then rotate the user hashes daily. He also speaks about a generic PtH control with blocking inbound NTLM to the domain.

The DFIR Blog has an excellent three-part series on many other detections and mitigations --

http://dfir-blog.com/2015/11/08/protecting-windows-networks-defeating-pass-the-hash/
http://dfir-blog.com/2015/11/24/protecting-windows-networks-dealing-with-credential-theft/
http://dfir-blog.com/2015/12/13/protecting-windows-networks-kerberos-attacks/

As for two-factor authentication and one-time password schemes, I don't think that FIDO (e.g., YubiKey) or a competing system would deter any of the above suggestions -- it would just add to their control strength and provide operational residual risk reduction.


Timing-safe string comparison in high-level languages

Note that you can't compute the bcrypt hash in the application and pass it to the database unless you store the salts separately from the hashes.  If you do that, you'll incur the overhead of performing a SELECT first, then the bcrypt, and then the password verify step.  Doing as the presentation suggests (having the DB calculate the hash) might make the most sense.  Postgres 9's crypt module does support bcrypt as a built-in hash type.

If you want to do the hashing in the application anyway, comparing with a hash is probably the simplest (least likely to have implementation issues).  Since bcrypt is based on blowfish, it only considers up to 448 bits of input, so you can safely hash the output with SHA-512 and mathematically will not lose any strength.  In reality, SHA-256 is fine as well, as users passwords essentially never contain more than 256 bits of entropy.  Even 256 bits of perfectly random printable characters would take 56 character long passwords.  Comparing using a hash is likely to have the most straightforward implementation, and since you already have the overhead of bcrypt, the cost of 2 additional hashes is trivial.

(This part of the answer is based on a misinterpretation of the question as being concerned about timing attacks against the application, not the database, but I'm leaving it here for reference.)

If you're using bcrypt, you've already hashed the password, so you don't need to be concerned about the timing results.  Even if someone could deduce the hash of the password, they'd still need to find a plaintext to provide to the application, which should be computationally infeasible (or bcrypt is broken).

Timing attacks are only useful if the attacker can iterate over the values being compared to find a useful comparison.  (i.e., A, B, C...)  With a hashed value, this is not possible, as they cannot iterate over the output of the hash (for cryptographically strong hashes). Small changes in the input to bcrypt result in large changes to the output.  A user providing the input to bcrypt has no way to try out prefixes and then extend the prefix.  An attacker would not know anything about either side of the comparison, and thus timing attacks do not leak any information about the value of the hash.


Limited remote access to a web application

Relaying purely on IP address to perform authorization is a bad idea. IP address can be spoofed.

Rather than attempting to verify user from the server, you should let the user prove to the server that they are authorized. This can be done by using simple login and password system. If you feel like this is not good enough you could always add 2NF. Here is a tutorial on how to implement 2NF in node.js, through bare it in mind that this is the first tutorial which I found on google. As it seems from this tutorial it should be relatively easy for you to implement 2NF for you application, and could result in higher security.

Another reason for why not to limit by IP address is, assume that the network from ISP goes down, or you are too far away from the network with specific IP and you must perform some action on the Raspberry. If you do authorization you could perform this action from the phone using mobile data. If you however block all different IP addresses, then your life will become harder in such situations, where this idea provides not enough security as the IP address can be spoofed.

While this post is based on PHP login system, I believe that the principles given there may be also useful for you.


How would "hardware verified" API calls be constructed?

Client-side certificates, in software, provide exactly this purpose.

Apple, for instance, bundles each of it's devices with certificates signed by itself as the CA. Thus any communication from an Apple device requires the server to authenticate the identity of the device. Having been signed by Apple, the client is thus authenticated and the communication proceeds.

As to can this be done in hardware, I think the only issue would be on the methodology to revoke the certificate.


Detect / Prove and Prevent Wifi Deauth attack

How do I know if i'm being attacked?

Detection of de-auth frames can be difficult to spot, you'll need software like nzyme (which is WI-FI monitoring software) along with something like Graylog, a WI-FI security management tool. Graylog enables you to analyze the wireless traffic hitting your network.
You'll find a much better explanation of each by just Googling the above software.

The above may help you identify if you are the target of such attacks.

Prevention

With regards to preventing it, there is no definite way of preventing de-authentication attacks.

If your AP supports it, you can enable 802.11w which increases the security of management frames and can assist with preventing these types of attacks, move info here:(802.11w)

Some people may suggest hiding your SSID. If your neighbor has a network card capable of injecting packets along with the know-how to send de-auth attacks, chances are he'll be able to suss out and discover you've hidden your SSID pretty quickly.

I can appreciate the pure annoyance of this is the entire point of wanting to block these attacks, however, these types of attacks can be much more devastating in somewhere like a coffee shop for instance, so I wouldn't be too concerned with regards to network security. (This doesn't take away from the fact this person still of course has the ability to try capturing the handshake and attempting a brute-force, see below for suggestion on how to near-eradicate this worry).

Suggestion

If this is your home network the best thing you can do if you are worried would be to create a strong, long password. Generate a 20 char one if needs be, just don't forget it!


BadUSB: Why are firmware writeable in the first place? Manufacturer's backdoor?

Everything is buggy.  Hardware, software, firmware, wetware.  Everything.

Most of the time those bugs fall within acceptable limits.  Whatever computer you're using, for example, probably has 5-20 BIOS updates, depending upon how old it is.  And for most people, they can be many updates behind without problems - because the bugs fixed by later versions either don't impact them or aren't catastrophic.

Sometimes bugs are more serious, and need to be fixed before something can be shipped / sold.  It would suck to manufacture a million USB thumbdrives, for example, then be forced to throw them out at a loss because of a bug that surfaced.  The manufacturer would be much better off if they were able to compensate for the bug (and firmware can often compensate for hardware problems, not just firmware problems).

So the general rule is to design systems that have a little update-ability, even if the normal lifecycle of the product isn't expected to require it.

Because everything is buggy.

WhiteWinterWolf asks this followup question in the comments:

  In the Black Hat presentation by Karsten Nohl and Jakob Lell, the
  solution presented as the most simple and effective one would be to
  lock the firmware down at the factory, blocking any firmware
  update. Following your answer, do you think that such possibility
  would therefore be not very realistic "in the real world"?

Now we're purely into speculation territory.  Here's my opinion:

Locking the firmware is a technical solution, but it's one that will only be embraced at the very low end (cheap, throwaway devices) and the very high end (security-focused marketing).  The vast middle will continue to ship writable devices because the business case edges out the security case.

Let me tell you how I got there:

Locking the firmware has positive (increased security) and negative (inability to update to correct issues as described above) impacts.

At the very low end - where you can buy an 8 GB thumb drive for $2 - the inability to update is less of a problem.  In all likelihood, the manufacturer is relatively generic, and won't mind the PR hit for having a buggy device that can't be updated.  And at that price, consumers are more likely to toss it in the trash and buy something else than they are to look for an update.

So the security benefit outweighs the business cost at the low end.  (Whether low end manufacturers can be convinced to take such a simple step is another question; by definition, they care less about the consumer, because they're not building brand loyalty).

At the other end of the spectrum, there are companies who market themselves as security-before-everything-else providers.  IronKey, for example, sells devices that wipe themselves if the wrong password is entered too many times, and which are baked in epoxy to prevent physical access.  For them to offer the trade-off of locked firmware (no updates, but less insecurity) is fine - that's their value proposition.  Their customers would rather throw expensive devices away than have security risks that could be avoided.

As for everyone between those two extremes...

Picture a presentation being given around a board room.  The presenter says, "We can improve our client's security, against a very unusual niche attack, by locking our hardware so that updates aren't possible.  There is a possibility this could cause high rates of product returns, negative publicity, and general damage to our brand.  We are here to decide whether to protect ourselves or a small, unknown subset of our customer base against an unknown potentiality."

They're going to vote to do the right thing for the company, not for the hypothetical individual customer.  And they're going to keep shipping things they can update.

Just my 2 cents (which is good enough to buy a 256 MB thumb drive these days).


Pentesting CTF exercise suggestions for very closed system

As with all things penetration testing, enumeration is absolutely critical.

Based on what you've told me, if I were in your situation I would do the following (assuming you have not already).

Ensure you run an nmap scan against all TCP ports

nmap -sV -A host -p 1-65535
Scan UDP ports - this will take a while but perhaps you have an unauthenticated TFTP server you can try to exploit
Run a Nikto scan against the web server - I assume you already did this based on your comment stating that the web server gives no information whatsoever but do it just in case.

nikto -h http://host
Run a dirb scan on the web host to see if you can find some previously unknown directories. You may also choose to use your top 1000 password file as a potential wordlist for this.

dirb http://host -w /usr/share/dirb/wordlists/big.txt
See what HTTP methods are allowed on the web server - is PUT or UPLOAD allowed?

curl -X OPTIONS http://host -i
Try an additional "primary enumeration" tool - instead of nmap, try Sparta which is a wrapper around basic tools which can automatically launch attacks, brute forces etc on detected services
Try running the HTTP-Enum nmap script to see if you can find any additional information that might be useful.

nmap -sV --script=http-enum
Try enumerating SSH users if possible - metasploit has a scanner for this

auxiliary/scanner/ssh/ssh_enumusers

Even though it looks grim now keep pushing forward and keep enumerating your target. The better your enumeration techniques and skills the more likely you are to find a hole to exploit.


First of all, thank you for taking the time to determine how to do this correctly and improve security for your users!

Migrating password storage while taking legacy hashes into account is relatively common.

For your migration scenario, bcrypt(base64(sha1(password))) would be a reasonable balance. It avoids the null problem (important - you definitely don't want to leave out the base64 stage!), sidesteps bcrypt's native 72-character limit, and is 100% compatible with your existing hashes.

You would simply hash all existing SHA1s with bcrypt(base64(sha1)), and then hash all new passwords with the full sequence. (You could also use SHA256 instead, though this would increase your code complexity slightly, to check to see if SHA1 or SHA25 was used (or to just try them both and pass if either succeeds) Long term, SHA256 would be more resistant to collisions, so would be a better choice).

For resistance to bruteforce, this would not only be equivalent to bcrypt, but would be theoretically superior (though in practice, 72 characters is so large for password storage than they are effectively the same).

Bonus advice:

Be sure to use a bcrypt work factor that is high enough to be resistant to offline attacks - the highest value that your users can tolerate, 100ms or higher (probably at least a work factor of 10). For speeds under 1 second, bcrypt may actually be slower for the attacker (better for the defender) than its modern replacements scrypt and Argon2 (YMMV).
Store the default value for the work factor as a system-wide configurable variable, so you can periodically increase it as your underlying hardware speeds get faster (or more distributed).


Can a bluetooth mouse be controlled by another bluetooth mouse?

The pairing code is not for authentication but merely for identification: two devices shows the same pairing code to let you know you are pairing the correct devices. Not all Bluetooth devices have a screen, so it's also possible to pair devices without the code.

In short, paired communications are encrypted and there's a key exchange, invisible to user and not related to the pairing code. Actually there are four security levels and two modes, explained well by Mark Loveless:

  Security Level 1 supports communication without security at all, and applies to any Bluetooth communication, but think of it as
  applying to unpaired communications.
  Security Level 2 supports AES-CMAC encryption (aka AES-128 via RFC 4493, which is FIPS-compliant) during communications when the devices
  are unpaired.
  Security Level 3 supports encryption and requires pairing.
  Security Level 4 supports all the bells and whistles, and instead of AES-CMAC for encryption, ECDHE (aka Elliptic Curve Diffie-Hellman
  aka P-256, which is also FIPS-compliant) is used instead.

Therefore, what you suggest wouldn't happen by accident. But there have been security holes in bluetooth pairing, too. (Also, it's a good prank to mix all wireless mice at the office, but that's on the physical layer.)


When it comes to something like a hardening guide, RHEL 6 is still considered fairly new. As sad as it seems, many of these types of guides take several months or years to produce. That being said, by and large, for your purposes the difference between EL 5 and EL 6 should be fairly minimal. When I began supporting EL 6, most of my changes were rather cosmetic. For instance, making sure to use rsyslog instead of syslogd. Since RedHat produces their own guide, a lot of the version specific work should be taken care of there.

I would, however, encourage you to check out the NSA Fact Sheet for RedHat 5 and the CIS Benchmark. Some specifics may change, but much of the core work should translate quite well.

I would also recommend checking out this related question: How to secure a dedicated linux server running a LAMP stack for commercial E-commerce use

It is worth noting that as of 2 June 2012 there exists a Red Hat Enterprise Linux 6 Benchmark from the Center for Internet Security.


How would you know a certificate/private key if you extracted it from RAM? Or would you?

Yes.  Most private keys have an easily identifiable format.

If its say an RSA private key generated with openssl, they have a specific format e.g., will always start with the same three bytes depending on key size:

30 82 01 (for 768 bit key or MIIB in base64)
30 82 02 (for 1024 bit key or MIIC in base64),
30 82 04 (for 2048 bit key or MIIE in base64),
30 82 09 (for 4096 bit key or MIIJ in base64).

There are some other types of formats that the private key can be stored in as well.

You can test this yourself with openssl using the commands: openssl genrsa 1024 (1024 means 1024 bit key to see the key in its base64 representation.
)

For more documentation on the format see this StackOverflow answer: Where can i find some documentation on the format of an RSA public key?


Example of malware that spreads via USB?

autorun.inf

[autorun]
open=file.bat
shell\option1=Open
shell\option1\command=file.bat

file.bat

@echo off
copy autorun.inf C:\ > NUL
copy file.bat C:\ > NUL
copy autorun.inf D:\ > NUL
copy file.bat D:\ > NUL
explorer .

Put them together, and you got something that will spread through USB.

On a more serious note, don't expect that someone will just hand you a piece of malware here.


Does HTTPS verify the domain in the requested URL matches the SSL certificate Common name?

It does check the DNS name matches the certificate, however it also validates if the domain name is in the alternative name field.
If you download the SSL certificate for www.seedprod.com, you'll find:
-----BEGIN CERTIFICATE-----
MIIGQzCCBeugAwIBAgIRAPdMB9xtmbIZDI9ahTm4MRcwCgYIKoZIzj0EAwIwgZIx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV
BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTgwNgYDVQQD
Ey9DT01PRE8gRUNDIERvbWFpbiBWYWxpZGF0aW9uIFNlY3VyZSBTZXJ2ZXIgQ0Eg
MjAeFw0xNzA0MjgwMDAwMDBaFw0xNzExMDQyMzU5NTlaMGwxITAfBgNVBAsTGERv
bWFpbiBDb250cm9sIFZhbGlkYXRlZDEhMB8GA1UECxMYUG9zaXRpdmVTU0wgTXVs
dGktRG9tYWluMSQwIgYDVQQDExtzc2wzNzgwOTQuY2xvdWRmbGFyZXNzbC5jb20w
WTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASu4JtvmTPQZHm10bG4CVuOg2O9qVWC
t09Hx0vBnLVoln7Z25glBjo8bPcQpzZ5ELnHiRDnfXOFip9mqx1Ha7ito4IERTCC
BEEwHwYDVR0jBBgwFoAUQAlhZ/C8g3FP3hIILG/U1Ct2PZYwHQYDVR0OBBYEFLoE
5sVmZxdES/mk31Ix6XhvqKbzMA4GA1UdDwEB/wQEAwIHgDAMBgNVHRMBAf8EAjAA
MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBPBgNVHSAESDBGMDoGCysG
AQQBsjEBAgIHMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5j
b20vQ1BTMAgGBmeBDAECATBWBgNVHR8ETzBNMEugSaBHhkVodHRwOi8vY3JsLmNv
bW9kb2NhNC5jb20vQ09NT0RPRUNDRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZl
ckNBMi5jcmwwgYgGCCsGAQUFBwEBBHwwejBRBggrBgEFBQcwAoZFaHR0cDovL2Ny
dC5jb21vZG9jYTQuY29tL0NPTU9ET0VDQ0RvbWFpblZhbGlkYXRpb25TZWN1cmVT
ZXJ2ZXJDQTIuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC5jb21vZG9jYTQu
Y29tMIICjAYDVR0RBIICgzCCAn+CG3NzbDM3ODA5NC5jbG91ZGZsYXJlc3NsLmNv
bYIgKi5icmF2ZWVhZ2xld2VhbHRobWFuYWdlbWVudC5jb22CFCouY29taW5nc29v
bnBhZ2UuY29tgg8qLmNvbW9sb2dpYS5jb22CDiouZGlub2Z1cnMuY29tgg4qLmVw
aWtjaGF0LmNvbYIVKi5oZWF0cHJlc3NuYXRpb24uY29tgg8qLml2YW50aS5jb20u
YXWCCyouaXZhbnRpLmN6ggsqLml2YW50aS5kZYILKi5pdmFudGkuZXOCCyouaXZh
bnRpLmZyggsqLml2YW50aS5pdIILKi5pdmFudGkucGyCDSoubXRhcGF5Mi5jb22C
FioucGF1bGhvd2VsbGRlc2lnbi5jb22CFSouc2Nwcm9wZXJ0aWVzLmNvbS5hdYIO
Ki5zZWVkcHJvZC5jb22CFCoudGhlYXJ0b2ZhZHZpY2UuY29tgh5icmF2ZWVhZ2xl
d2VhbHRobWFuYWdlbWVudC5jb22CEmNvbWluZ3Nvb25wYWdlLmNvbYINY29tb2xv
Z2lhLmNvbYIMZGlub2Z1cnMuY29tggxlcGlrY2hhdC5jb22CE2hlYXRwcmVzc25h
dGlvbi5jb22CDWl2YW50aS5jb20uYXWCCWl2YW50aS5jeoIJaXZhbnRpLmRlgglp
dmFudGkuZXOCCWl2YW50aS5mcoIJaXZhbnRpLml0gglpdmFudGkucGyCC210YXBh
eTIuY29tghRwYXVsaG93ZWxsZGVzaWduLmNvbYITc2Nwcm9wZXJ0aWVzLmNvbS5h
dYIMc2VlZHByb2QuY29tghJ0aGVhcnRvZmFkdmljZS5jb20wCgYIKoZIzj0EAwID
RgAwQwIgOaCjhzo/ys/XgLJOgT/bqjtBr49RL8mzmD1a3FP6DnICH0YLws0/K04O
LSik+0+yFS3pTsnK44ONkX1NccykTvI=
-----END CERTIFICATE-----

If you put that in a file seedprod.crt, you can then use openssl to view the full data in the certificate with openssl x509 -in seedprod.crt -text.
Then you will see:

X509v3 Subject Alternative Name:
DNS:ssl378094.cloudflaressl.com, DNS:*.braveeaglewealthmanagement.com, DNS:*.comingsoonpage.com, DNS:*.comologia.com, DNS:*.dinofurs.com, DNS:*.epikchat.com, DNS:*.heatpressnation.com, DNS:*.ivanti.com.au, DNS:*.ivanti.cz, DNS:*.ivanti.de, DNS:*.ivanti.es, DNS:*.ivanti.fr, DNS:*.ivanti.it, DNS:*.ivanti.pl, DNS:*.mtapay2.com, DNS:*.paulhowelldesign.com, DNS:*.scproperties.com.au, DNS:*.seedprod.com, DNS:*.theartofadvice.com, DNS:braveeaglewealthmanagement.com, DNS:comingsoonpage.com, DNS:comologia.com, DNS:dinofurs.com, DNS:epikchat.com, DNS:heatpressnation.com, DNS:ivanti.com.au, DNS:ivanti.cz, DNS:ivanti.de, DNS:ivanti.es, DNS:ivanti.fr, DNS:ivanti.it, DNS:ivanti.pl, DNS:mtapay2.com, DNS:paulhowelldesign.com, DNS:scproperties.com.au, DNS:seedprod.com, DNS:theartofadvice.com

Note DNS:*.seedprod.com and DNS:seedprod.com are in there, so the certificate validates for seedprod.com.


How could I validate a security architecture?

At the end security is a just a fix like any other, its effectiveness can therefore be tested the usual way you could test any fix:

Test the vulnerabilities while your security is not installed or is disabled and confirm that the environment is indeed vulnerable.
Enable/apply the security system.
Test again in the same conditions, and confirm that the vulnerability is not exploitable anymore.

Do not fall into the trap of skipping the step 1: it is essential to concretely ensure that your test can effectively demonstrate the presence of the issue. Too often people only do the steps 2 and 3, but for some reason their tests while possibly good in theory may not be effective in the real world (environment specificities, unknown side-effects, etc.). This is often how one can end-up implementing useless fixes.

The only thing specific to security is that these testing phases may require the use of specific knowledge and tools, but since you seem to say you have already identified these vulnerabilities and designed a potential mitigation solution then I suppose that in the worst case a few web searches should be sufficient to bring you all missing parts.


How to share an encryption key between different PHP applications?

As @schroeder recommended, you should share the key between applications/servers using Public Key Infrastructure (PKI). It's not recommended that you implement this yourself.

There is a great article called Choosing the Right Cryptography Library for Your PHP Project. This is worth taking a look at. It recommends the following libraries:

Halite
Libsodium (as recommended by @NSSec)
PHP Encryption
Phpseclib (RSA! Only)

Others to consider:

EasyRSA (Not PKCS#1v1.5!)
phpseclib

Also since there are corporative apps involved, have a strategy for key management on the respective servers (i.e. key management processes and policies, use of a Hardware Security Module (HSM), etc). You can also consult Guidance for Securing Public Key Infrastructure.

Good luck with your project!


Design proposals for enhanced security for parts of Internet, e.g. for banking?

My guess, from reading the article, is that the envisioned network is mostly the Internet as we know it, except that thanks to some trickery with regards to the (US) constitution, the presence of a ".secure" at the end of the name allows a (US) agency to deploy various eavesdropping measures. The proposed system should allow only "authorized" users, which probably means that whoever wants to operate a ".secure" machine will have to give a copy of its SSL private key to the CIA/NSA/whatever, or something like that. They could call it "Revenge of the Clipper Chip".

There is nothing really technical here; only legal. The whole things is impressive in its americanity (a US legal gimmick for the benefit of the US agencies, with "consent" stemming from the word "secure" -- that's not .sécurisé or .seguro or .sichern or .terjamin).


How many qubits are needed to factor 2048-bit RSA keys on a quantum computer?

Actually the question must be clarified, that in which time you want to break RSA, for example scientists say that RSA with 512-bit can be broken in 6 week with quantum computers, but with how many qubits? So time is important, 2 qubit can break 2048-bit but in which time? Because in quantum computers each qubit can be 0 and 1 in each moment, so n qubit can handle 2n state in a moment, if number of  qubits are increased the break time decreases(reverse relation). For example 2048 qubit can handle 22048 state in moment. Also only qubits are not enough, qubits are memory for quantum computers. More qubits mean you can factor bigger numbers.

According to mentioned paper:

... If large quantum computers can be built, then RSA ciphers become useless.
It is estimated that 2048-bit RSA keys could be broken on a quantum computer comprising 4,000 qubits and 100 million gates. Experts speculate that quantum computers of this size may be available within the next 20-30 years.

Quantum Computing and Cryptography

And according to this one:

Quantum memory units are called qubits and the largest quantum computers capable of running Shor’s algorithm only have about 20 qubits. (A Canadian company called DWAVE has a quantum computer with 512 qubits but it has very high error rates on its qubits and is based on another principle called quantum annealing.) To run Shor’s on 2048 bit RSA would require at least 10,000 qubits. It will probably be a while before such a machine can be built.

Online security, cryptography, and quantum computing


Gmail shows my photo after I enter my emaill address (but before my password)

In the past I have noticed that the full name of the account holder was sometimes displayed too, before entering the password. But not systematically, it seemed to be account-dependent. Perhaps the OP can confirm this.

There is a potential breach of privacy here, even if you put a picture of your cat. Because many people reuse the same image for their profiles on other sites such as forums or social network sites. A simple reverse image search can often match a picture with other profiles and ultimately a real identity.
This is one of the most basic doxxing techniques.

If your real name is already embedded in your Gmail address, you probably don't care. If you have some made-up address, that you use to register, post (and sometimes troll) on forums, maybe that should concern you because you are not as anonymous as you think you are.

Think of it, at one point, we have all upset someone with something that we wrote, for good or bad reasons. As a result, we may have had to deal with stalkers at least on one occasion.

Everything you post can and will be used against you. A picture is very often uniquely identifiable data and the metadata sometimes tells a lot: for instance a raw picture from a tablet, camera or smartphone will often have GPS coordinates embedded in the EXIF data. Plus the name and model of your device. Normally the thumbnails will drop all EXIT data but you still have to think twice before posting or uploading anything.

The EXIF can even get you in trouble with the tax authorities. A famous example is late french singer Johnny Hallyday betrayed by pictures posted on his Instagram and Twitter accounts. The geolocation metadata revealed that he spent little time in Switzerland, where he claimed to have fiscal domicile.

Therefore, I recommend using exiftool to systematically strip all EXIF data from your pictures before uploading them to a site. As easy as:

exiftool -all= picture.jpg

The tool has plenty of other options, including bulk options. You could also fake some of the data if you want to have fun with adversaries.


auditing open source compiler binaries for trojans

It is not actually "well known". The story comes from a classic must-read article from Ken Thompson. Though it was implemented at that time as a demonstration, it would be challenging to do it on a larger scale.

The main problem here is about software updates. For the malicious binary chunk to be reinjected in the compiler, should the compiler be recompiled with itself, that code must know where, precisely, it should hook itself. And this may change between versions of the compiler. When a GCC developer makes some changes in the source code, he may unwillingly break the hooking mechanism of the hypothetical replicating virus, and he would not know it. But future changes by developers cannot be predicted, let alone be accounted for in a virus which must then work in an autonomous manner.

Or, said otherwise, succeeding at writing a piece of (malicious) code which resists more than 20 years of updates and overhauling of a software as complex as GCC, would be a remarkable engineering feat, and I doubt mankind as a whole knows enough about computers to achieve that. Yet.

In the old Thompson situation, the C compiler software was not changed, only recompiled, and that made the whole thing easy (a fun and philosophically challenging eye-opener, but still technically easy).


Are there known hacks or security problems on broadband USB dongles?

To answer your exact question, to the best of my knowledge no security vulnerabilities from USB dongles have gotten any attention in the past years. I guess that was what you're looking for?

However, there are known cases of rogue USB devices that are used to backdoor computers. Some security companies doing penetration testing and social engineering combined, even leave behind USB sticks with malware on them at the offices of targets. And of course, there's Stuxnet, which reached the nuclear facility by USB stick. So in general, I'd be reluctant to plug unknown USB devices into my computer.

Also, one often needs to install crappy drivers from the telco in order for the dongle to work. I usually don't really trust those :-)

And don't forget that the broadband connection itself is probably being monitored by the telco. Sometimes all HTTP requests are pushed through a transparent proxy. I'd recommend to VPN out of the telco's network first, and do al your interwebsing over that VPN.


Are there limits (or, what are the limits) to our understanding of AES's resistance to known plaintext attacks?

A perfect block cipher is modeled as a pseudorandom permutation. For blocks of n bits, there are 2n! possible permutations; a perfect block cipher is as if the key was a random uniform selection of one permutation among all these. For a PRP, knowing many plaintext/ciphertext pairs (m, E(m)) gives you exactly zero information on the encryption of blocks m' which are not part of the known pairs.

Right now, the best attack we know which may distinguish AES from a PRP is the so-called biclique attack, which has a cost only very slightly lower than basic brute force on the key (cost is theoretically about 2126.1, compared to 2127 for brute force -- needless to say, the attack cannot be actually tried with existing technology, so we are not absolutely sure that it works as advertised, though that is plausible).

Assuming that AES is indeed as good a PRP as we can get, usual encryption modes can be shown to be "secure" as long as you haven't processed more than 264 blocks with the same key. That's the point where, statistically, the PRP begins to be differentiated from a PRF. It translates to about 300 millions of terabytes, which is kind of large. AES has been defined to use 128-bit blocks, and not 64-bit blocks like 3DES, precisely so that we do not run into that kind of problem.

To sum up: in practice, you don't have to fear reusing the same key again and again, as long as you do it correctly (e.g. CBC mode requires random uniform unpredictable IV).


UUID in URL - how safe from accidental discovery is my proposed solution?

It's not very safe, but depending on how sensitive the file actually is, you may consider the risks worth the usability benefits.

  Can a robot index such pages and their UUIDs?

Yes, if someone posted the link to the file on the public internet, then they can be indexed. With major search engines, you can ask search engines to exclude this directory by using robots.txt, but compliance with robots.txt are voluntary and there are many other spiders that ignore robots.txt.

If you want to secure this without losing much of the usability, you may want to consider requiring viewers to create individual accounts to access your site. The viewers should enter their email, and you'd validate their address by sending an email with a confirmation token, you'd then send a message to the document owner to ask them to grant access to the user identified by their email. Additionally, you may want to allow the document owner to specify a list of email domains and addresses that will be automatically granted access, so that he wouldn't have to manually grant every requests. Most companies give their employees email addresses on a company domain, so this would cover a lot of use cases. This way, each user that accesses the document will still be identified, rather than being an anonymous user.

If you really don't want to require users to create an account, it is possible to implement this without requiring user password, when user type their email, they'll be sent an email which contains a link they'll click that have a unique token that grants them access to the document for a short period of time. When the short term token expires, the user can request a new token.


Does Apache Tomcat 9 meet PCI compliance?

Individual software packages are not judged compliant or non-compliant by PCI.  Rather, the organization using them is required to attest that they are following PCI-approved practices where they apply to that software.  A limited subset of examples:

  6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and
  assign a risk ranking (for example, as “high,” “medium,” or “low”) to
  newly discovered security vulnerabilities.

This requires that the merchant track vulnerabilities (for example by reviewing the list here) and patch or apply compensating controls to ensure the merchant's installation of Tomcat 9 is not vulnerable to attack.

  6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor supplied security
  patches. Install critical security patches within one month of
  release.

Keeping Tomcat 9 patched is another requirement imposed by PCI.

  6.4.1 Separate development/test environments from production environments, and enforce the separation with access controls.

This is an excellent example of how your practices matter; this is not anything intrinsic to Tomcat 9, but rather a constraint upon how you choose to use it.

As always, the best source to learn more about PCI DSS is the document itself, available from the PCI Security Standards document library.