Replace certificates simultaneously on remote servers?

How can we make this two-side replacement process accurate and easy?

The conventional way to do this is to support multiple certificates in the verification side. The verifier side should install the new certificates, which should work side by side. The signer then can swap to the new certificate at the time of their choosing before the old certificate expires.

Note that in most use cases of asymmetric cryptography, the verifier generally would need multiple certificate support anyway because the verifier might need to verify old messages using expired certificates. In these cases, the user should be notified that the verification is successful with an expired certificate.

If you really can't support multiple certificate, you would need a synchronized downtime. First, the signer is taken down, and it flushes all unsent messages; then after the verifier finished processing all pending messages, the verifier is taken down. After both asides updated their certificates, the services can be brought up again. If the signer is capable of queueing unsent messages to be resent later, then the signer can restore service at any time after the verifier is confirmed to be down; otherwise the signer had to wait for the verifier to be up before starting up.

If you really can't tolerate downtime every time the certificate expires, then what you could do is use a certificate chain verification. In this scheme, you'd create a long-lived root certificate (e.g. 10 years or more), which is used to certify shorter lived leaf certificates (e.g. six month, yearly); the verifier would accept any certificates that are anchored to the root certificate. You'd still need to synchronize downtimes to replace a root certificate, but replacing leaf certificates wouldn't need to be synchronized. You would need to guard your root certificate very dearly though, because this root certificate is hard to replace if compromised.


Why encrypting with ECB block cipher mode provides different result?

The reason that you are seeing different outputs each time you use openssl enc -e -aes-256-ecb to encrypt the same plaintext with the same password is because openssl is using a different random salt each time you run it.  The salt is combined with the password to derive the encryption key, which is fed into the aes-256-ecb algorithm.
If you specify the encryption key directly (instead of deriving an encryption key from a password as you are doing), using the -K option, you should see that openssl enc -e -aes-256-ecb produces the same result each time given the same plaintext and same key.  For example, the command below produces the same output each time you run it:
echo -n "1234567890abcdef1234567890abcdef" |  openssl enc -e -aes-256-ecb -K dba50aff3f87d7d41429f9b59380ac539cc62a89adfdefcd5157015e0e768382 | hexdump

When specifying a password instead of a key with openssl enc, the first eight bytes in the output are the ascii codes for the string 'Salted__'.  openssl puts this in the output to denote that the next eight bytes are the salt.  You can verify this by running echo -n '53616c7465645f5f' | xxd -p -r.  This produces Salted__.
For more info on all of the above, see Where is the salt on the OpenSSL AES encryption?.


Stopping DDOS TCP SYN and UDP flood attacks

SYN Flood can be mitigated by enabling SYN Cookies. SYN Cookies prevent an attacker from filling up your SYN queues and make your services unreachable to the legitimate user.

On Linux, those are some settings you can use to enable and set up SYN Cookies efficiently:

echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 2048 > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo 3 > /proc/sys/net/ipv4/tcp_synack_retries

To make those settings load automatically on startup, add those lines to the file /etc/sysctl.conf:

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 3

It is possible to protect a Windows box too, as its described in this article by Microsoft. Windows Vista and above have SYN attack protection enabled by default.

As of UDP flood, unfortunately there isnt much you can do about it. Howover, in a ICMP/Ping flood, you can setup your server to ignore Pings, so an attack will be only half-effective as your server won't consume bandwidth replying the thousands of Pings its receiving.

You can do that by running this configuration:

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

And naturally, add this line to the file /etc/sysctl.conf:

net.ipv4.icmp_echo_ignore_all = 1

But bewere some watchdog systems require ICMP Echo to be enabled in order to work. Some rent servers will require you to leave ICMP Echo enabled because of that. But you can still use iptables to disable Ping in only some interfaces.

On Windows this can be done with the command:

netsh firewall set icmpsetting 8 disable

Windows Firewall must be active.


Which certificate on my computer is used to make a SSL/TLS handshake

Unless you specifically configure your web browser to use a client certificate for the site that you're connecting to, your browser does not use a certificate to make the SSL/TLS handshake with the server.

Instead, your browser receives the server's certificate, and verifies that it was signed using a certificate in your browser's or OS's certificate store that the browser trusts.  There may be one or more certificates in this chain of trust.  You can view this chain by clicking the padlock icon in the address bar of your web browser.  The certificate at the top of the chain is the certificate that your browser trusts, so this is the certificate that you would want to transfer to your second computer.


RFC6125, 6.4.4 (from 2011):

.... the client MAY as a last resort check
for a string whose form matches that of a fully qualified DNS domain
name in a Common Name field of the subject field (i.e., a CN-ID)

RC2818, 3.1 (from 2000):

...Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.

Apart from that, not everything is regulated through RFCs. If CAs and browsers agree to a behavior they don't need to write an RFC an each case.


Indeed the question is pretty interesting. Either way it boils down to a risk assessment plus controls in place of each system. Roughly, we could imagine 2 undesirable consequences of long-life session:

Somebody can just open browser with your logged account. Controls:

Close all sessions from another device via Account settings if you suspect that your personal device has been stolen.
Lock your personal device. Except that the session is 15 minutes long, there is no big difference between 7-week session and infinite session: somebody can use your computer if you don't lock it, and the session is usually being renewed infinitely until you use device. So you should lock your device and close all sessions from another device if your computer has been stolen.

Somebody can steal your session ID and open it on another device. Controls:

User notification about that via Push Notifications, SMS, e-mail.

About controls in place of mentioned systems, let's look at each case:

Stack Exchange has 1 week rolling session. Controls: you can login with Google or with custom e-mail, you can remove sessions, you can logout.
GitHub has 45 days. Controls: there is a two-factor authentication (2FA), session control, backup e-mails, SSH keys, logout.
Gmail has never-ending session. Controls: suspicious login detection, alerts, 2FA, backup e-mails, everything....

Keep in mind that the difference between 7 days and 45 days session policy is kind of subtle: while session is still active somebody can just open your browser if you forgot to lock your device. Therefore it looks like there is no too much to do about a not locked device, but GMail has pretty huge control about any suspicious activity. Anyways, security engineers select expiration time from their internal security risk assessment which may differ from case to case, it may differ from our perception, there is always a portion of subjectivity.


If you consider that attackers may recover the RAM contents (a cold boot attack) then you have to take into account that attackers may recover the RAM contents. Your /tmp filesystem is used by application as a temporary repository for some data elements, but the same applications read it back -- into RAM. That is, the RAM-based filesystem is unlikely to contain the only copy in RAM for the sensitive data. Whatever you do with /tmp, be it encryption or anything else, will only be a partial solution.

Another point is that an encrypted filesystem is still a storage for files, that the live system can read and write. Thus, even if encrypted, the decryption key (in the live machine) must be somewhere in it... i.e. in the RAM. If attackers can read RAM, then they can recover that key, and remove all your encryption.

What you could do to lower the probability of data recovery by attackers is to make sure you empty the RAM as part of the shutdown procedure. This would entail, from the last process running in the machine:

Unmounting /tmp.
Deactivating swap space (by the way, do you encrypt your swap partition ? Alternatively, you could simply deactivate swap; I do that on my laptop).
Filling the RAM with random bytes (or zeros), allocating pages and filling them until allocation fails. At that point, you know that the kernel found all available RAM and filled it with randomness; this would include all pages that were corresponding to the RAM-based /tmp.

From what I explain above, such a procedure would both be necessary anyway (since sensitive data may lurk outside of /tmp), and makes any encryption of /tmp irrelevant.

Remaining issues are that non-application RAM, in the kernel space, might still need some cleansing; and a shutdown procedure has any effect only when a shutdown is applied. If the attacker steals the live machine, then he may pull the plug (or the battery, for a laptop) to get a fresh, live snapshot of the RAM. Encryption would not help you there (because the encryption key would be part of the snapshot).


It is a little bit of a grey area, as everyone interprets it a little differently, but consistent aspects of Secure by Design include:

an architecture which has security built in by default
a code design and review process which has sufficient checks
developers/designers/architects trained in security
automated checking
continuous monitoring through development (esp DevOps)
4-eyes checking

Etc.

It puts the emphasis on getting security built in early, instead of counting on remediation after the fact.

This has some obvious benefits, including a dramatically lowered lifecycle cost.

To clarify as per jpmc26's comment, building a secure architecture means designing it to have layers of protection, to avoid obvious holes (and also to avoid having accidental holes appear), to default-secure or default-closed when things fail, to understand the security requirements before starting to build so they don't need to be added on afterwards...etc.


How should I store a physical written copy of my password?

You need to take your threat model into account. Will people literally destroy a house to get your backup password? Will anybody even look for it?

You also need to take into account how likely you are to forget the password, and what kind of information will be available to an attacker that recovers it.

Assuming that you are not under a severe threat, simply writing it down and storing it in a fairly secure and nondescript hiding place will do. Place it in a book, tape it underneath your sock drawer, etc.

If there will be people actively looking for it, you may need to take more spycrafty (is that a word?) steps, such as laminating it and burying it in the ground, placing it in the freezer inside a piece of frozen fish, spackling it into a wall and painting over it, placing it inside a pen, etc.

You can also take several random values, xor them together, and use that as a key to encrypt it. Keep the encrypted copy in the open, then store the random keys in different locations, so that all will be required to regenerate the key and unlock the password. This may be a more secure method regardless of how the distributed secrets are hidden, because it will increase the work of someone looking for it, especially if they do not know how many secrets are required to regenerate the key.

If the information is very sensitive, you should increase the security level even if the threat is low. Required security = threat level * damage from exposure, in this case.


Secure way to store application settings

Ok, so if a hacker gets into your system you want prevent him to seeing the configs? By the logic, IMO this is not possible. The application needs to read the config and it needs to store the config values in the memory. The hacker with root privileges can always dump the memory and reconstruct the config (if the application is running).

However, you can make it harder for him. For instance, you can keep the config encrypted. The application would ask for the password on startup and use the password to decrypt the config. However, I can imagine, this could be quite annoying for sysadmins ;-)


How secure is using this (p3 Python) module to encrypt a file?

Making your own crypto algorithm is considered a bad idea unless you are a cryptographer and are willing to spend a lot of time creating/testing it.

The algorithm in P3 is (according to the mailinglists) created by a guy who knows his stuff, but it's not a standard. I suggest using AES instead if you want to use passwords (AES is a symmetric encryption algorithm).

The problem at the moment is that there are no readily available modules for Python 3 that come with AES support. For Python 2.x there is Pycrypto, an excellent library for any cryptographic algorithm, but it's still getting ported at this time to Python 3. However there is a branch that already contains AES here.

Now how tough would it be to crack AES with a 10 to 20 character password? Very tough. If you use the most secure one (which is AES 256 at the moment) and your password consists of only numbers,upper and lower case letters. Then you would have (26+26+10 possibilities for one letter)^10 (all possible combinations). This is a huge number of passwords you'd need to try (statistically half the amount actually). Because of the complexity and CPU load AES can cause, it would take over one hundred thousand years to crack it.


Can I determine actual origin of spoofed text message?

Your carrier is definitely able to tell who sent the text, as the sender's carrier's servers obviously connected to your carrier's ones to deliver the message and everything was logged.

They just don't want to go through the effort of diving into log files which would require paying for engineer time because the people who work at their customer service are only trained to sell stuff and don't even know what is a "spoofed SMS" (the incorrect explanation they told you proves it, no matter what software sent the message they should still have a log of where the message came from, whether it's their network or some other carrier).

Your friend should take legal action for identity theft, then the police will force your carrier to disclose any info they have about that SMS, including the origin carrier, from there they contact that carrier and they should be able to give them the identity of the person who sent the text (or at least, some possibly anonymous IP if it's an SMS API provider, but it's still worth a try).

The caller ID or SMS sender is just a string field without any particular meaning, while you can't spoof that using your mobile plan because your carrier always puts your number in that field on their side, you can definitely spoof it if you are a carrier yourself and have direct connections to other carriers, in which case you can pretty much put anything in there and your call/SMS will be delivered just fine with that (spoofed) caller ID/sender. Most SMS APIs offer that as a service so companies can send marketing messages originating from "company name" instead of a phone number, but of course the actual sender is logged on their servers for obvious purposes.


Why in Bash?  I guess technically you could use curl to post data and then see if the data gets echoed back to you without being escaped... but really, why limit yourself to bash?

Take a look at "Gray Hat Python", "Coding for Penetration Testers: Building Better Tools", or "Violent Python: A Cookbook for Hackers, Forensic Analysts, Penetration Testers and Security Engineers" for Python examples that do this.

See also: https://www.owasp.org/index.php/Testing_for_Cross_site_scripting


What's the purpose of signatures in Google Maps APIs?

Referrer restrictions are typically enough to prevent someone from reusing your API key in JavaScript on their own website, because the browser enforces the referrer information. But outside of a browser, referrer information can be easily faked (see: referer spoofing). So those restrictions are not enough to prevent someone from using your API key to send requests from a server, or from an offline tool. I believe preventing that is the purpose of these digital signatures.


How do I improve the physical security of a rack cabinet?

In a home/small office setting:

One thing you can add is to anchor the rack to the floor. Also use Kensingtons to secure your hardware to the Anchor or the rack frame.  Use front panels for your servers (these can be locked picked in under a minute if you are handy though) and consider putting a chain around your rack so the door can't be opened (padlock secured).

While this may seem weaker (considering you have a locked rack with steel panels), it is just a cheap and extra layer to slow a burglar down.

In the end physical security like locks and anchors can only slow down an attacker so much.

You might also consider putting the rack in  a locked room and/or install an alarm system.

Cheap
If you are on a too low budget to afford alarms,  you might try to attach disk-brake burglar alarms for motorbikes to the rack,  they are cheap (30 euros) but they can make a very very loud noise for a long period of time. They detect vibration (when you open the door when it's armed or when someone is fiddling with it)


The more layers you add above the actual data, the harder it will be to securely erase it, because it could have been stored in caches, journals, etc.
Most SQL databases first store information for data modification in a rollback segment to be able to rollback the transaction. Unless a specific database has an option to securely wipe the rollback segment, you should take care of it yourself, and depending on the database, it could be hard if it is even possible.
Furthermore, for security reasons, many professional-grade databases offer a journaling feature. This is a nice recovery feature in case of a crash: you re-install a backup, and replay the journal files registered from the backup date. It guarantees that all records added since that backup are stored in the journal files.
And this does not account for possible caching operations...
Said differently, if you want to securely erase some record, you are better off storing the record directly in a file and preferably not on a SSD drive*. That way, you could rewrite the records many times with a well-known erasure pattern making the original record un-recoverable.

(*) ssd drives can write a new version of a block in a different place. Most offer a secure erasure of the full disk, unsure for the secure erasure of a disk sector.


In what situations can a hacker try to break passwords millions of times?

Mass brute force is usually done after the attackers have somehow seized a list of hashed passwords. This can happen in several situations; most common being:

A SQL injection attack which allows attackers to push some more or less constrained SQL expressions to be evaluated by the target database. Depending on the site structure and local constraints for the attack, attackers might not be able to do what they wish with the database, but still be able to dump some parts of it.
Data is extracted from a discarded medium, e.g. an old hard disk; possibly an electronically broken hard disk, that the attacker retrieves from a dumpster and repairs.
Indelicacy from an employee or intern, who stealthily grabs a copy of the database and stores it on a USB Flash drive.

The common trend here is that cracking passwords is used to extend an attack:

Attacker got a read-only glimpse of the database, and wants to escalate that into read-write access.
The original breach is risky (e.g. attacker had to be physically on the premises) and wants to come back to the server, but from the network and without incurring the risk of an encounter with security guards.
Attacker wants to get the password from one server because he knows that most users will reuse the same password on many other servers.

The third point is probably the most common motivation for attackers.


Prevention of devices using same OTP secret

If you're designing your own authentication app; instead of scanning the OTP token, scan an authorization token that will then be used to retrieve the OTP from a server. The server can then be setup to only release the token once. Bundle certificate pinning into your application, and you're good to too.

The flow would look like this.

User requests OTP token from website
User opens app and scans QR code, which contains one time use API key
App then contacts server, verifies certificate with pinned cert
App submits one time use API key, server returns OTP token and marks the API key as defunct.


Authenticating client without hardcoding key?

It's not possible to authenticate a client in this way. As you correctly point out, it can always be reverse engineered and duplicated. Server authentication only works because the user doesn't have access to the server hardware, and to produce a secure client you must find a way to block the user from accessing the client hardware, which is generally impossible.


I'm not sure where you are from. First of all his opinion is against the the considered industry best practice as defined by NIST. Furthermore your manager is dangerously wrong. The more users the more likely it is to get the same passwords for several users. Also the following companies do it and I'm quite convinced that they have a larger global user base than your website:

Facebook
Gmail
Linkedin

Also another reason which is something you can explain from a business perspective is the risk of image/brand damage when  you get negative publicity. To give you an example Adobe used a bad implementation for password storage which lead to the same issue as you are having now: the value resulting from hashing (in case of Adobe they were using encryption rather than hashing) the password was the same for several users if they were using the same password (in their case due to not using an IV while performing symmetric encryption, but this is not relevant). This caused a massive storm of negative publicity, after all an internet company should be adhering to something as simple as password hashing no? The financial cost resulting from such negative publicity can be significant.

Also depending on the country where you live and the laws employed, these days the management can be held personally accountable if it is determined that they were negligent when it comes to protecting data privacy (if cracked passwords are used to get personal data of users for instance). Also depending on the type of information stored, financial, medical, credit cards, different rules may apply which can result in other types of fines as well.

This is something which might not be relevant for password hashing directly, but might come in handy if your manager makes further bad decisions. So make sure to make copies of emails where you clearly explain the problem and also save your managers reply. (just to cover your own ass)

The fact that you are not using salts also probably means you are not using a correct hashing algorithm, as these often take care of the generating salts and performing an amount of iterations. The three accepted algorithms are:

PBKDF2
bcrypt
scrypt


Is it a bad idea to have the user choose the TOTP secret instead of generating it automatically?

A better question would be: why would you do that?

When you develop an authentication protocol, you control all the variables. This means you can ensure, for instance, that the RNG you use is secure, that you're not reusing an existing secret and that you aren't picking a "weak" key.  Plus, you don't have the problem of relying on a secure side channel for retrieving the secret from the user.

When you allow the user to generate their secrets, you throw all that away.

The only historical advantage of having users select their own secret is that they can commit them to their memory and not rely on (potentially insecure) local storage. In case of TOTP, you don't even have that advantage: your users needs to rely on some form of software to obtain the current code (which is the point of 2FA: force the user to have access to "something they have" in addition to "something they know").

So, yes, it's not too good an idea.


It can be.

Generally speaking, programs while running don't tend to wipe out their data (they do, after all, tend to need it), and any process with the ability to access other programs' allocated RAM can, in fact, read it. This is how, for example, the recent spate of big box store hacks were able to leak so much credit card data -- the attacks were carried about by rogue programs that scoured the running POS machine's RAM and copied anything that looked like card data. [I can't at the moment find a source to back this one up, I'll keep looking and edit it in later.]

Once a program terminates, the data that was in its RAM may remain around indefinitely if no other process gets allocated those same addresses and overwrites it with its own data. On modern operating systems this again requires the ability to read RAM not allocated to the process doing the reading1, and even then is unreliable at best, especially on modern systems that are constantly doing all kinds of things.

Both of these can be mitigated, if not outright prevented, by never allowing untrusted processes to run with root/administrator privileges: limited users simply do not have the ability, barring holes in the OS's security model, to access this RAM.

And, of course, there's our good friend the "cold boot attack", where encryption keys etc. are read from RAM after the machine has been powered down. This requires physical access to the machine, a boot disk (or specialized hardware), and quick timing (as data remains resident in RAM for only a short time after it's powered down).

As a quick footnote, the risks of data remanence on hard drives are rather overblown: Once data's been overwritten, it's gone. The "Gutmann 35-pass method", for example, is not only a fundamental misunderstanding of Dr. Gutmann's research, but wholly unnecessary -- a single pass with any data -- ones, zeros, random noise, kitty pictures -- is all that's really necessary. If it's not overwritten, however -- if it's merely deleted -- then it does hang around, though. Data remanence on RAM is similarly an often-overstated risk, though just like hard drives it can and does leak information if you're not careful.

1 The reason is that modern operating systems actually take the time to wipe out RAM before allocating it to a new process, specifically to avoid leaking potentially sensitive data to processes that start up and then read uninitialized data (which in the past is how such leaks were carried out).


Sensitive issue regarding windows 8 password

Looks like the photos are stored in hard disk. If you can find a way to remove the hard disk and connect it via USB, then possibly you can find the files you are looking for.


How to protect users from malware utilizing protocols such as DNS over HTTPS?

By looking at the non-DNS traffic, as you should be doing anyway. Remember, malware can use raw IP addresses just as easily as it can use DNS-over-HTTPS.


What to do if a webpage on the dark web is blocked because I need to enable JavaScript

JavaScript on its own shouldn't be a problem in the context of a darkweb browser such as Tor. The browser is configured to use a proxy and JavaScript can't magically get around that in order to reveal your real IP.

The problem is that JavaScript can be used as part of exploits. If there's a vulnerability in your browser, a malicious page might be able to exploit it in order to get code execution on your box, or otherwise perform operations that deanonymise you.

If you trust the site and you're accessing it over HTTPS, feel free to run JavaScript on it. Shouldn't be a problem. If you're accessing over plain HTTP then I would be more concerned, because a malicious exit node could inject malicious JavaScript.


I agree with @polynomial, this sounds like a scam. Facebook would never call you, there's no such thing as a Facebook tech. Do not pay them any money! It could be that your computer has been infected and that you are getting pop-ups telling you that your computer is infected and you need to call a number to get it fixed, this is also a scam where they sell you a fake AV tool that will remove the so-called virus.

If someone has called you out of the blue then tell them to take a long walk off a short pier. Make sure your computer has all OS updates, Adobe updates, Sun Java updates, etc installed. Also make sure you have an antivirus installed and it is up to date. Microsoft has a free one that is actually pretty good.

If you have pop-ups on your computer telling you that your computer is infected by a virus, then it is. The virus gives you a pop-up telling you your computer is infected in hopes you'll fall for the scam. The only way to recover from this is to re-build your computer. Get a portable hard drive and copy your important files to it, then completely re-install the operating system. Make sure it has all the updates on it, and an Antivirus program. Use the AV to scan the portable hard drive and if it is all clean then copy the files back.


I have to encrypt the file, because anyone who can change it can get
  one cent drinks.

Encryption is used for confidentiality - to prevent unauthorized parties from reading the file. Since your goal is to prevent people from changing the file what you need is a digital signature.

There are two kinds of digital signatures: asymmetric signatures and symmetric signatures.

When using a symmetric signature the side checking the signature needs to have the same secret key used by the signer. In your case this means that the secret key needs to reside in the machine's firmware which sits on the same SD card as the file your trying to protect. Not very secure.

When using an asymmetric signature the side checking the signature (i.e. the vending machine) has a public key and doesn't have the private key needed to sign a file, which solves the above problem.

But this is still trivial for an attacker to break. Since the firmware if on the SD card, and we're assuming the attacker can modify the SD card, the attacker can simply modify the firmware so that it doesn't check the signature.

The ideal solution for this would be if the vending machine's hardware (e.g. BIOS) would validate a signature on the firmware before loading it. There are embedded devices in the world that do this (e.g. game consoles, mobile device) but vending machines are not one of them.

Given the lack of a firmware signature check there is no way to achieve real security for this. The best you could do is obfuscate the code so that it would be more difficult for a hacker to reverse engineer and modify.

If you have good reason to believe that attackers cannot modify the firmware then all you need to do is sign the file using RSA with PKCS#1 padding (which is good enough for your needs). Delphi code for this can be found in TurboPower LockBox; OpenSSL has C code.

Having said all that, there doesn't seem to be much of a threat here. If an operator lowers the price for a specific machine then you should be able to identify the discrepancy for that machine between the amount of drinks that were put into the machine and the amount of money that you got out of it. This is something you need to check anyway to ensure that the machine operators aren't simply taking money (which is clearly a more severe threat than stealing a few drinks).


Should Administrators regularly change their passwords

Yes; admins should not be rotating their passwords either. As an administrator my passwords are completely randomized and stored encrypted. For me to change my password only adds "secret" rotation. However, me changing my password to yet another random password doesn't add any security in whether or not the password can be cracked or not. I would actually argue that if your current random password is not in a dictionary somewhere and then a new random password you pick you're rolling the dice that the password is also not in a dictionary somewhere and also harder to crack; so each time you change the password when there is no reason to you are rolling the dice that the password may be harder to crack.

NIST SP 800-63B agrees with me believe it or not:

  Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

Basically, with the assumption that your password policy is sufficiently complex, you should only have users change their password if they feel like it (personal preference) or force them to if you suspect their account may have been compromised.

Another valid reason to not change your password regularly when its un-needed is that normal users will almost always use a simple variation of the previous password. For example, if their password was mTpaGFrsYht12 they make it 1mTpaGFrsYht12; if their account was compromised then any password cracking tool like john would discover that new "rotated" password. Not to mention, if someone has compromised the network and is collecting hashes, each new password change is a hash and therefore a new password that the attacker can store in their database and attempt to crack offline.

The problem with passwords in security authorization is weak passwords, not strong passwords with weak secret rotation.


I find that many cases the device needs some kind of malware installed on it without user knowing:

Fake malware apps that look like Facebook/twitter,
Bundling malware within genuine apps,
Targeted Bluetooth attack,
Etc.

At some point they would need some type of control software to command over (hence command and control), and yes it is possible.

You need to pay attention on to what you're downloading and using. In most cases phishing rules apply here.

As I am not as coding technical as many others are my answer for you is very policy and common sense based. Hope it helps.


Why can you bypass restricted WiFis by adding "?.jpg" to the URL?

Most probably the blocker is designed to let images through, maybe because they are hotlinking some images on the page where they ask for you to login.

Appending ?.jpg to the URL makes the blocker think that the URL is an image. On the other hand, anything after the ? doesn't change the actual webpage requested, it only changes the GET headers. (so http://google.com/?.jpg and http://google.com/ give the same page).

Note that if there already is a query string in the URL (something after a question mark), then you must use &.jpg instead of ?.jpg, as only the first question mark is considered for making a query string (the second question mark is considered as part of the data, generally, and this may lead to you getting the wrong page)

Basically, when you fetch a page, you can provide additional data to the server (which can then send you a custom page dependant on your data). There are two ways of doing this: a GET request and a POST request. A GET request puts the data in the URL itself, a POST request sends in in a more subtle, 'hidden' way. Here is an example GET request on the "ask question" page of SuperUser. A note: it is not necessary that there is data when you use a GET request. When you fetch a normal webpage, that is also a GET request, without data.


Is Remotely wiping a cell phone really a valid defense?

There are definitely some things to keep in mind with regards to remote-wipe software, most of which you seem to have already realized.

It should not be relied upon.  It's definitely a great contingency to have available but, as you've stated, it's very probable that an (arguably unlikely) attacker who's more interested in your information than he is in the phone's hardware value would try to find a way to circumvent it quickly.
Any remote wipe you perform will likely be after the thief has already had your phone for some time.  This means it is very possible that the thief might already have copied off whatever bits of your information that they were interested in, before you performed a remote wipe.  In this case, even if your wipe is successful, the data is still out there.

In short:  If your phone is stolen, and you have remote wipe capability, you will want to perform the remote wipe as quickly as you realize the loss.  This will help to minimize (but can never fully negate) the likelihood of actual data theft occurring.  Even then, you must still presume that all the data on your phone has been leaked, and take reactive measures accordingly.

Here, I'd also like to refer you to the 10 Immutable Laws of Security, if you haven't already read them.  Particularly applicable in this case, are these:

Law #3:  "If a bad guy has unrestricted physical access to your [smartphone], it's not your [smartphone] anymore"
Law #10:  "Technology is not a panacaea."

To answer your title question:  It is indeed a valid defensive measure, but it should not on its own be at all considered comprehensive.


Feeding Azure portal logs into a SIEM solution

As part of the Security Center GA announcement MS introduced the preview of a log integration connector for SIEM integration.  I haven't tried it out myself yet, but I imagine this will be the new recommended solution for your request.


What is the expected performance impact/loss of meltdown/spectre patches?

The full impact isn't known yet. It is also going to differ massively based on workload - code invoking large numbers of system calls is likely to invoke a notable hit whilst any difference to code mostly operating in user mode is unlikely to be measurable.

Epic Games has already blamed the patches for service outages.
Some artificial benchmarks have shown drops as drastic as 50%.
Intel initially put out predictions of 5-7%.
Toms Hardware have found no difference outside margin of error on a storage based test (Storage is one workload expected to be hit hardest).


certificate used in SSL and keys used in SSH

In theory yes. Don't do this though. It may break one or both of your encryptions and increases the chances of security breach in other ways.

Also, you definitely do want to authenticate the server when using SSH!


If a mobile app pins the Root Authority Certificate of a server and verifies its hostname, is it possible an attack via DNS-poisoning?

... it should be possible to an attacker to redirect in some way the victim to a malicious website with the same Root CA.

This will only be possible if the client blindly believes any certificate signed by this CA. This level of trust should of course not be done if the root CA might also issue certificates to an attacker, as is the case with common public CA. That's why a TLS client is supposed to verify if the subject of the certificate matches the expectation too, i.e. if the specified target hostname or IP is covered by the certificate.

... pins the Root CA but verifies the hostname of the server which the app is connecting to

That's what a properly written app will do.

If the attacker owns a website under the same Root CA, can he poison DNS-cache and let the app connect to his website or there are security mechanisms which prevent such behaviour?

The client should check the subject of the certificate with the intended hostname or IP. While DNS lookup of a domain might result an alias (CNAME) this will not change the intended hostname, but is only an internal step in getting the IP address. This means DNS poisoning against the client cannot be used to change the intended domain and therefore the attacker needs to have a certificate for the intended domain - which the CA should not issue since the attacker cannot proof to own it.
But, DNS poisoning against the CA might be use to fake the proof of ownership in domain validated certificates. In this case the attacker could get a valid certificate for the target domain which then can be used against the client, for example in a DNS poisoning attack against the client.


What's the point of the client secret in OAuth2 if it doesn't need to be used?

There are a number of different grant types supported by OAuth 2.0, and they enable the client application to interact with a resource server on behalf of the resource owner in different ways.

There are security implications to using an implicit grant, which is the type that does not require a client secret.  Specifically, in this authorization flow, the client (since there is no client secret) is entirely reliant on the resource owner (the user with the browser, generally) to obtain, present, and retain the access token.   This significantly raises the bar required for protecting the token (you really can't have an application relying on this grant type that isn't completely protected by TLS/HTTPS) and there's additional risk of the token being stolen and misused without the client application's knowledge.   Because of these additional risks, the RFC specifically recommends that you not rely on implicit grants unless you have to.

If your application does have the ability to properly protect a client secret, it is recommended to use the authorization code grant type instead.   This allows the authorization flow to be managed via the application, and removes the requirement for the resource owner to handle the authorization process externally, and opaquely to the client.  This means that the client can protect the access tokens as well, and does not need to rely on the users to keep them safe.

So, the client secret is not an extraneous option.  It is an integral part of the preferred option.  The implict grant type that does not require a client secret is simply a last resort of sorts for client applications that do not have the ability to implement a better option.


Uploading file with VPN...can they see my real ip?

Can they tell that I have uploaded it from my real IP or will they see my VPN IP?

Yes.

The connections should come from your VPN IP, if that type of traffic goes out across it.

They may also be able to tell your real IP if your browser runs their code and that code reveals other IPs.  As a single reference see http://www.wilderssecurity.com/threads/can-java-script-show-real-ip-address.223112/.

For a further remediation, try a TAILS LiveCD - read all the warnings on that site, too.


different results using nmap with/without sudo

Nmap adapts its techniques to use the best available methods using the current privilege level, unless you explicitly request something different. The things that Nmap needs root (or sudo) privilege for on Linux are:

Sniffing network traffic with libpcap
Sending raw network traffic

You can use the -d option to see what Nmap is doing in the background, but the short answer is that with root privilege on an Ethernet LAN (like you are using, based on the IP addresses you listed), Nmap will send raw ARP packets and sniff for results. Responding to ARP requests is a prerequisite to IP communication on such a network, so it's nearly impossible to block or hide from this type of scan. If you do not have root privilege, Nmap falls back to trying to connect to 2 TCP ports (80 and 443), considering the host "up" if the connection succeeds or is reset. A system with a drop-all firewall and no services on 80 or 443 will not show up with this scan. You can read more about Nmap's host discovery techniques in the host discovery section of the man page.


Trying to tunnel a reverse shell out of an internal network

I have solved my issue.

TL;DR: TCP 53 was available to incoming/outgoing traffic

When checking which protocols were allowed through the firewall, I was checking DNS by using 'host google.com' and 'host -T google.com' and 'dig @8.8.8.8 google.com' and when I did not receive the expected response I assumed this meant DNS was not allowed. After coming back to the machine a couple days later I decided to setup 'nc -nvlp port#' on my attacking machine and try to connect from the victim machine using multiple ports and long behold it was able to connect via port 53. So from there I setup my payload, got my shell and then escalated privileges.

So the lesson I learn was do not rely on a results from a single tool or method. Try more than one method.

As a side thought, if anyone has some insight into why my 'dig' and 'host' commands did not work even though it would accept traffic on 53, that would be great. I guess it allowed traffic over 53 just not DNS specifically?

Thanks for the suggestions


How does one scan a MySQL database for malware?

Interesting question. First you have to define what kind of malware you are looking for. In this case this might be:

Malicious data: Modified data that lost integrity.
Malicious code: Established, embedded or modified data that is capable of running (e.g. executable binaries, stored XSS).

If you are trying to detect malicious data you might chose one of the options:

Analyse the data for integrity by using regex. This might take a lot of time for preparation because you have to know how exactly your data structures have to look like.
Compare legitimate data to the current data sets to detect differences. You might create a hash value of fields, records or tables and compare them once in a while. Storing them in the same database might not be advised. Use another database or even another medium for that (e.g. a file-based approach). If an attacker is able to compromise the database and influence integrity, he might not be able to do the same on the file-system.

This approach might be able to detect malicious code also. But you might be able to use other techniques to detect it properly:

Use a signature-based approach to determine malicious code fragments. The easiest way is to screen you fields. But this expects the data to be in a format which is understood by the scanning engine. If you are serializing or encoding your data, this might hurt the detection possibilities.
You might want to create a dedicated API access possibility for you scanning desires. Your database must provide the data like it would be within an attack. For example if you are using your data within a mail attachment, your API shall create such an attachment to make it possible to be scanning how it will be in the end. Other examples are file-based and web-based output.

Signature-based scanning approaches are error-prone, inefficient and slow. If you have the chance to establish an integrity checking as soon as data is written, this might be much more solid.


Can password based SSO be trivially compromised?

Technically the Password-based Single Sign-On from Azure AD (from your link) is not an SSO solution but a password management one. The external application has its own credentials including password, and a plugin installed in the browser types them into an HTML form on behalf of the user, exactly what Lastpass does.

That means that those credentials have to been managed individually: created for a new users and revoked if user leaves. No doing so will indeed leave open security breaches, and the linked page in clear on that point even when credentials are managed by an administrator (emphasize mine):

  The credentials are obfuscated from the end user during the automated sign in process; however they are technically discoverable by the user using web-debugging tools, and users and administrators should follow the same security policies as if the credentials were presented directly by the user.

That means that you should have different credentials for each user and individually revoke them if the user leaves.

Only in true SSO solutions like SAML or CAS where there is one single account shared by multiple applications you have one single password to revoke.


Should anyone support / implement P3P policies? Do they matter? Are they legally binding?

I agree with most of the previous responses, but note that the FB and Google compact policies might be considered fraudulent due to the fact that they omit P3P elements and the way the P3P syntax is defined, omitting an element is an affirmative statement that you do not do the practice represented by that element. (See for example section 3.3.4 of the P3P spec: "Service providers MUST disclose all that apply. If a service provider does not disclose that a data element will be used for a given purpose, that is a representation that data will not be used for that purpose.") Also, the policies might be considered deceptive since an IE user might rely on IE to block cookies from websites without CPs and these CPs are designed to evade IE's blocking. However, I am not a lawyer.

There is a class action lawsuit pending against Amazon on a similar matter
http://www.infolawgroup.com/tags/p3p/

And there is a relevant research paper at
http://www.cylab.cmu.edu/research/techreports/2010/tr_cylab10014.html


Are server nonce and client nonce in SSL equal?

The nonces on the server and client side are created independently from each other. This means they are most likely not the same.

  If they are not equal, then it seems that the server and client must compute Master secret twice, one with client nonce and one with server nonce

The master secret is computed by including both nonces since both nonces are known on both sides, one because it was created locally and the other one because it was received by the peer. For the details see TLS 1.2 section 8.1 Computing the Master Secret:

  master_secret = PRF(pre_master_secret, "master secret",
                      ClientHello.random + ServerHello.random)
                      [0..47];

ClientHello.random and ServerHello.random are what is called nonces in the document you refer to.


How secure/private is the browsing history on browsers?

Aviator has had actual security (not privacy) issues and is nominated for this year's Pwnie awards.

In general, browsers will not share your history with websites you visit. There have been vulnerabilities in multiple browsers that would allow a website to get your browsing history or guess if you have visited some specific websites or not.

The vulnerability above could not have worked when using private mode because that instance of the browser didn't have access to your browser history.


After it has been blamed for not informing its users which protocols it uses, Zenmate says it relies on  TLS 1.2 (RFC 5246) protocol with 128-bit AES-GCM data encryption, SHA256 data authentication and ECHDE RSA handshake. So from the encryption standpoint, it is good and it is even rewarded for that. The problem with Zenmate is that its free service may be more limited by time (Zenmate is a commercial company) and the plugins itself keeps running even if the browser is closed thus consuming CPU and memory resources, and remember that Zenmate is not a full VPN service but it only encrypts your Chrome sessions.

As for Browsec, it is also recommended and just as well seen as Zenmate but for the etc you used in I regularly uses VPN addons like browsec, Zenmate etc in my browser, it all depends on which plugin you are talking about: As a good safety practice, you should use a browser plugin only if really necessary. And before installing one, being informed about it (why not review its code or see if some community did that, its rating and so on) is a good thing. There are even free opensource browser plugins developed as  POCs of how a plugin can compromise seriously user's privacy such as ZombieBrowserPack that can be manipulated remotely to steal authentication credentials, and even bypass two-factor authentication mechanisms such as the ones implemented by Yahoo and Google. It can also hijack your Facebook account, or get your bank account credentials if you perform an online purchase. You can imagine such a plugin purposed to fulfill this or that feature (shim) and doing something nefarious behind in the background.


Where are the apple-app-site-association files cached/stored on iOS when Universal Links are used?

It's stored in keychain. You check it on device, after wiping out keychain you lose universal links.


Scanning multiple hosts with Nmap's Default Accounts NSE script not producing the expected result

Scanning multiple targets at once should not make a difference. You may have a bug in your fingerprint code, but I can't tell without seeing it. If you want better support, open a new issue on the Nmap issue tracker with the following info:

output of nmap --version
output of your scan with the -d option for debugging output
Relevant contents of my-fingerprints.lua
Does the script work with the built-in default accounts fingerprints, or do those show the same irregularities?

I'm willing to bet that just running your scan with -d will show output from the script under each target, and the output will be a useful error message.


Can I generate a double cookie CSRF token on the client with JavaScript?

I would not recommend this. For the token to offer any protection, it must be unpredictable. Math.random() is not cryptographically secure - there is no guarantee that an attacker can not generate loads of random values, detect the pattern, and then deduce previous values thereby finding the value of the secret token. This is called "cross domain Math.random() prediction", and you can read more about it here and here.

I think (not sure, though) that most modern browsers protect against this in practice, but that is an implementation detail I would not bet the security of my application on. Actually, MDN warns against it:

  Math.random() does not provide cryptographically secure random numbers. Do not use them for anything related to security. Use the Web Crypto API instead, and more precisely the window.crypto.getRandomValues() method.

So can you just switch to getRandomValues()? Only if you are fine with 80% browser support.

Before doing this, ask yourself why you can't just generate the token on the server instead. If you go for the client approach anyway, at least avoid these two pitfalls:

Make sure that no token in the form and no token in the cookie does not pass! A naive equality check could let that pass, since both are an empty string, but that would open up a vulnerability.
There must be no URL that loads a page and automatically submits a form, adding the token in the process. Such an URL could be abused.


Many DSL modems are open from the WAN side for use by the telecompanies (you can try telneting from the wan side and see if it's open on your modem, try default username/passwors [1]), while it could have been the ISP that changed the DNS-servers it seems unlikely as the IPs are not in the same range.

Like you said, the most likely intrusion vector is a simple cross site scripting attack. To guard against XSS is generally hard, usually there is not much a user can do other than keep the browser updated. Changing the password will of course fend off the majority of such attacks but still leaves you vulnerable while logged in to the modem.

Worst case scenario (probably(?) low likelihood) would be a change of the modem firmware, there would have been a downtime of a few minutes as the modem restarts. What you would be left with in terms of data leakage is anyones guess but the theoretical worst case would be a compromising of all network traffic that's not end to end encrypted with endpoint authentication (like SSL).

The change in DNS-servers in itself would have leaked all non cached domain name requests to the third party with the potential of the DNS owner to provid false DNS results. (Say for example giving the IP of fakebank.com when you requested the IP of mybank.com, or just giving you a the right site but with extra ads). This is a more likely scenario.

[1] http://internetcensus2012.bitbucket.org/paper.html


Man in the middle attack, bridging wlan interface to virtual wired interface at0

The problem is clear! you don't have a DHCP server to provide an IP to the mobile phone.

You have two solutions:

Make sure that your Wlan0 is connected to a network with a DHCP server, 'for example: your home network', so when you make the bridge the phone will have an IP.
install a DHCP server apt-get install dhcp3-server and configure it to provide IPs.

Either ways, you forgot an important thing to do, make your system to re-forward the packets using the command:
echo 1 > /proc/sys/net/ipv4/ip_forward


Can renew expired Microsoft CA Code Signing cert?

Few things to know:

you cannot renew expired certificate. This is because existing certificate is used to sign renewal request. Since the certificate is expired, it cannot be used to sign request. Even if you try it, CA will reject renewal request because it was signed by an expired certificate.
instead of renewal, you should go to the same process you went for initial code-signing certificate enrollment. Just enroll a new one and use it to sign the data.
I discourage ADCS Web Enrollment usage, because it offers very and very limited functionality and requires ActiveX. Especially, for Enterprise CAs. Instead, you should consider to use Certificates MMC snap-in which provides powerful tool for certificate enrollment.


Is this technique a secure way to confirm a user's bank account details, without requiring them to provide their credentials?

I think that the mechanism could in theory work, provided that the user can trust it's bank that their site is setup in a way so that no sensitive information are transferred within the "proof" session. That means at least that only the information  relevant to  the proof are included in the proof session, that the HTTP session id can not be used by the third party and that no TLS session reuse is done, i.e. that the same key is not used to protect previous or following TLS sessions.

This means that not only the user needs special software to create the proof session but also that the bank needs to be setup in a way to securely support this proof. In my opinion this makes this concept too complex and too unreliable in practice.


backdoor php trojan still dangerous on my local machine?

If I understand your question correctly, anti-virus will report a file as malicious even if that file cannot be executed on the machine it is on. For instance, a Windows-only virus found on a Mac can still be identified by anti-virus as malicious.

This is a good thing because you might pass on those files to others. Malicious is malicious, even if there isn't an imminent threat to the local machine.


Does Google use the ISP's IP addresses as a frontdoor for their services/servers?

The #1 think you should start with is to check the site's certificate chain. It should resolve to a root from this file. See https://pki.google.com/faq.html for more details there. I'd also expect to see Google Internet Authority G2 as the intermediary signer.

I know of other large Internet companies that deal with personal information who have placed edge termination devices into ISP spaces: It's not just Netflix that does this. It does seem odd to use other address space, but I think the SSL chain is the telling point.

... So I went and looked at the certificate chain myself. The certificate is registered to *.googlevideo.com, and I'm assuming from  https://peering.google.com/about/faq.html that it's a Google Global Cache device. That it's googlevideo.com specifically hints that it only gets a certain type of directed traffic.

Multiple domain names is one way a provider may allow caching of some traffic (e.g., video content) without disclosing more sensitive information routed to other domains (related user ids or sensitive services such as email).


Local area network multi-device network communication protocol

If slave doesn't have to acknowledge that message was received, use UDP protocol and send message to broadcast. About using encryption. I would choose asymmetric encryption (RSA). Master will have a database of public keys of slaves and only recipient (selected slave) could decrypt message while any other slave in network will ignore it. For controlling multiple devices at the same time, you will simply share another private key with several slaves.

About re-sending malicious packets (AKA replay attack). Widely used solution it to add at the begining of communication nonce (random or pseudo random number) and increment it with every command that master send. Therefore you could check if massage was replayed or not.


Is it bad to add a guessable password to a random password?

Certainly a longer password with comparable or higher complexity, like your example, results in a safer password.

Though we have to say what "safe" means in this context. An attacker should not be able to brute-force the login. A long and complex password also adds to the security if an attacker would ever get their hands on the password database (if they don't store them as plain-text).

There are actually two scenarios regarding password security which are affected by the complexity and length of your password. The first one is an attacker who is only able to test against a black box, e.g. the login of a website. If your password would be too trivial like "password" then an attacker can gain easy access, even with a lot of security mechanisms in place (excluding two-factor authentication). This becomes much harder for an attacker the longer the password gets, especially since most websites limit login attempts.

The second scenario is a database breach where the attack has access to the password database. The security of your password, meaning "Is the attacker able to figure out my password?", does not only depend on you, but how the website handled all passwords. If the store them in plain-text you loose, no matter how complex they are. What is insecure, but often occurs, is simple hashing with no salt or a global salt for all accounts. In this case it helps having a complex and long password, because what the attacker does, is checking the hashes from the database against pre-computed lists of common passwords or even entire dictionaries of combinations. A long and complex password means more attempts are necessary for the attack.
A properly secured website should use a per user salt (and perhaps pepper), making rainbow-tables and dictionaries pretty much useless. This would even protect fairly simple passwords, but still the longer the better (or safer).

So the reason why you should use long and complex password is the first scenario and the second scenario in case of improper security. You can see as well, that the actual security also depends on the web-developers not just on your password.


How updated is the HTTPS Everywhere list?

You are looking at someone's fork. https://github.com/EFForg/https-everywhere is very frequently updated, with 131 commits the last week.


Same-origin policy considers all of these origins to be different:
http://example.com
https://example.com
ws://example.com
wss://example.com

So if browsers were to apply SOP rules to WebSockets, if a page at https://example.com tried to connect to a WebSocket at wss://example.com it would fail.
In theory WebSockets could have been designed to use CORS headers during the initial HTTP handshake, but these two technologies were developed at roughly the same time.


Is there a Snort rule that equates to "something suspicious flagged from a client side application?"

Snort looks at network activity, so it would have to be something that the client-side app sends over the network. At that point, you would need to look at the messages that the client sends out, which could be grabbed by Snort. Pre-defined? No, there are too many client-side apps to catch them all.

Snort rule template:

  alert tcp any any -> any 80 (msg: "Client Unhappy";content:"Client unhappy text";nocase;)

This rule is pretty basic, but it's the place to start. To reduce false positives, you would also want to look at the ports the client and server use to communicate messages and refine your rules to look there.

Here is a SANS guide on how to look for certain text, and refinements.


Usage of the permanent RSA private key in ECDHE-RSA-AES scheme

No, in TLS_DHE_RSA_* and TLS_ECDHE_RSA_* cipher suites, RSA is used by the server only to generate digital signatures and by the client only to verify digital signatures.


Is there a unique way to identify a hardware?

uuid.getnode() in python returns the MAC address of one of the network interfaces installed - if there are none, it returns a random 48-bit number with the eight bit set to none as per RFC 4122.

That's as likely as good as you'll get.  The UUID of the computer doesn't exist but often certain pieces of hardware have unique identifiers such as the CPU and any network cards.  Of course, any of those bits of hardware could be swapped out.  Since uuid.getnode() returns a random 48 bits on failure, and those 48 bits aren't secure, then you are much better off just using something like Crypto.Random.random.getrandbits(N).

All that said, you can identify a Windows computer to a small group, even if it's not unique, by looking at the key.  How you do this will depend on your language, but it is definitely possible.  You could also look at all the drivers currently loaded and use that as a method, which Windows itself has used and means a hard drive taken and inserted in another system won't work.  Of course it also utilises information in TPM etc.

As stated in my comment, if you want a repeatable seed for running experiments then set it manually.  If you want a random string, use various options available that have a high degree of entropy such as mouse movement.


Whats the difference between an evil twin and a rogue access point?

Yeah, but an Evil Twin is a kind of Rogue AP.

The most common Rogue AP is an ilegitimate AP that is plugged in a network to create a bypass from outside into the legitime network.

An Evil Twin is a copy of a legitimate AP. The target is different. It tries to hook clients to connect to the fake network to steal information, but is a kind of Rogue AP too. A lot of people is wrong about this. They think an Evil Twin is not a Rogue AP but it is too. Look at the definition on Wikipedia: Rogue AP. You can read there "... it is tagged as rogue access point of the second kind, which is often called an Evil Twin".

The Evil Twin has too "good" or "positive" usage. It can be used during a pentesting over a corporate network to measure the "security education" or better said, the user's security awareness. To see how many bite the lure.


Security Certificate not from a valid authority

You could try to access the link from a browser and check the certificate details( like in firefox: Edit -> Preferences -> Advanced -> View Certificates ).
Enusre that various fields like issue to and dates are correct.
Please post the details if that is feasible.Also which email client are you using ?

Since "Security Certificate not issued by a valid authority" is exactly what it means and there are no changes done on your part, go ahead and mail to your ISP already.


The tactics basically amount to guessing:

Standard directory testing: This guesses typical webpage files, like /manager/login.jsp and the like.
Dictionary Attacks": This guesses dictionary words, like "employee".

There are many tools that do this, like Burp Suite and Dirbuster.

The other technique that I like to use for finding hidden pages is searching Google. Simply putting in site:*.example.com will return every single page on example.com that Google knows about. So, if Google-Bot has stumbled upon your page, I'll know about it too!

There's also the chance that someone will just guess it. It's not that hard. Now, a page like example.com/lsjglkjlktjwlkfjsldkjfijflkwjflksdjflkdsjflkdsjf would be quite hard to find :)

Takeaway: if you don't want someone to see it, put an authentication challenge on it.


How to check if all PC programs are using the VPN's IP?

In general, IP routing isn't program specific, but  the next-hop is selected based on the routing table, in this order:

Destination address matches a directly connected network.
The routing table contains specific route for the destination network.
Default gateway.

Depending on the VPN implementation it might add routes that falls into category 2 or a default gateway with a lower metric value. The real IP might be exposed if the routing table contains a better route through that interface. Also, if communication to private networks (10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16) is possible, it never uses the VPN.

This also means that the results from whatismyip.com and alternatives might not be globally true even on the web browser. Check your routing table and learn to interpret it.

Also, any program using networking automatically without actions from the user will continue making connections when the VPN is down. Many websites do this, too; don't leave your browser open unattended.


Is there a default assets grouping in order to perform Information Security Risk Assessment?

There is no specific methodology you can do it as per your organization structure,asset distribution, asset usage etc.
However, as per ISO 27002 under clause 8.1.1 mentions that the asset inventory should be made along with ownership and classification (see 8.2) information.
When you look at the 8.2, it mentions that assets can be classified in terms of its legal requirement, its value in organization or process, criticality of asset and sensitivity of asset in terms of information it holds is secured from to unauthorized disclosure or modification.

Based on above classification then it would be easy for you to identify the risk for the assets as it has already been classified in terms of criticality and sensitivity.

Hope above explanation helps.


Email including self-shredding macro after "Seen" flag is set

No, it's not possible. It would be difficult to implement securely, and also pointless because of all the ways to get around it. What if Alice saves the email externally? Or screenshots it? Or uses an email client that doesn't support macros? If something is displayed on someone else's screen, there's usually nothing you can do to prevent them keeping a copy of it forever if they want to (this is why even with all our clever cryptography, online piracy is still a thing).

However, if Alice won't realise immediately that it's something she wants to keep a copy of, you could achieve a similar effect by making a post somewhere on the internet - ideally your own website - and emailing her a link. Then you can delete the post, so the link is useless. Alice can still copy the message, but only if she does so before it gets deleted.


How does Google protect against scraping?

One "obvious" way that comes to mind (but I have no idea whether Google does this) is it is looking for related requests that a browser would generate after retrieving the main page.

A browser will retrieve the main URL and then (for a typical page) request several additional items: JavaScript files, images, CSS files etc.
Depending on how you're scripting the get (e.g. you only mention "make an HTTP GET request") if it sees repeated requests for "main pages", but no interleaved requests for .js/.css/.jpg files, then it might assume you are a script.


What would be the best way to evaulate the database management systems?

I am not sure that I understand your requirements, so I will assume you want to prevent offering vulnerabilities to nefarious actors, rather than pen-testing until doomsday.
Further assumptions:
- You are connected enough with your organization to review source code with the developers.

I would start with the OWASP recommendations.
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

Much of this will rely upon scanning the source code rather than rigging up a framework to feed your databases sketchy queries.  Please let me know in comments if this is NOT what you mean, or if your INFOSEC group is not tied in with the developers.


Yes, this is same as Private Key Cryptography

  Symmetric-key algorithms are a class of algorithms for cryptography that use the same cryptographic keys for both encryption of plaintext and decryption of ciphertext.

Z=F(X,Y) is same as C=F(P,K) where C=Ciphertext, F=symmetric algorithm used, P=plain text, and K=user defined key.

AES and Blowfish are two commonly used algorithms.


Why do botnets use IRC but not a web service for communication?

There are at least two types of schemes how to controls botnets:

via C&C;
decentralized scheme;

The following ways of C&C botnet networks exists:

IRC (one or many);
control via web servers;
internet messengers;

Without C&C:

peer to peer networks;
trust rings;

Combined schemes are also possible, thus taking the best of each technology. It is not rare case when botnet developers creates their own protocols to leverage the capabilities of control.

First of all, IRC is used because it allows simple way to deploy communication network. For very small amount of bots it is enough with one IRC server, when server is unable to handle some peak moments of when bots online, several IRC servers can be joined. But, this type of networks is not for serious botnets nowadays. See my comments here: Malware known to use port knocking to evade detection by network scanners?.

By minimal complexity control via web server is similar to IRC. However, it allows more possibilities of control scheme variations. Is easy to deploy, control and to loose too. One of the most popular ways how to control botnet.

Control via internet messengers is not popular, because it is hard to create such network without headache for botmaster. Registration of accounts for one person is not a problem, but when it comes to automation of process, the problems starts.

Peer-to-peer botnets are hard to develop, but they can provide more stable and robust network.

The so called "trust ring" is even more complex scheme, but because of it's way of decentralized scheme it is hard to kill it. This is similar to scheme that is used in Skype.

C&C botnets are easy to create, but also easy to kill - just destroy control center. The last two types of C&C-less botnets are often seen used in serious botnets, because of really serious authors intents to be in big business of bad boys.

By the way, botnets are used not only in malicious purposes.


What are the security implications of Digital Lifeboat (or other p2p storage solutions)

I remember someone being left with a bad impression about Digital Lifeboat in November 2012. His comment below was featured in the Security Now podcast.

  I recently started getting unsolicited and unexpected email from
  Digital Lifeboat, an online PC backup service.  It appears that
  somebody set up an account using my email address by mistake, so
  Digital Lifeboat have been sending me updates about the PC being
  backed up on the account, with links to their website.  If I wanted to
  access this person's account, with all of their personal information
  and all of the data in their backup files, I simply have to go to the
  Digital Lifeboat website and request a password reset using my email
  address.  It is just the customer's dumb luck that I am too scrupulous
  to do so.  Even if I don't do anything, though, they are still not
  getting any notification emails - I am - and they will never be able
  to reset their own password because everything goes to my email
  address.

  I tried unsuccessfully to contact Digital Lifeboat by email and their
  webpage so I could warn them about the risks they are taking by not
  verifying customers' email addresses during account creation, and
  possibly to find a way to contact the customer without invading their
  privacy.  But none of that worked.  So today I finally posted on their
  Facebook page and did receive a response from a man who initially did
  not understand the issue and then proceeded to tell me about an even
  bigger problem.

  He wrote, quote, "I forgot that our two-factor cell phone
  authentication is currently disabled.  When we disabled it, we left
  this gaping hole in our security.  Wow, that's our screw-up.  Thanks
  for bringing it to our attention.  I'd like to delete this thread so
  as not to advertise this issue, and we'll address it internally."
  That thread was deleted, but not before I took a screenshot of it.

  It worries me to think of all the people trusting this company with
  their personal information and backup data because they're not being
  told the truth.  Digital Lifeboat touts "256-bit AES encryption to
  insure complete privacy and security of your data," but what good is
  that encryption when they don't bother to protect the customer's
  account?  It's the same thing we were talking about earlier.  They
  clearly have awful security practices, and I'm still not sure they
  even understand the initial problem I brought to their attention.


IP cameras or webcams and wifi/network security

Preventing the camera from talking to the outside world is trivial, or nigh impossible, depending on how evil the camera is. On one hand, any decent router should be able to block or not-block traffic from any local IP to the outside world; therefore, you may configure your router to:

assign a specific IP address to the camera (based on its MAC address);
block all non-local traffic to and from this IP address.

If the camera is "mostly honest" this will work. However, if the camera is intent on evading your measures, then the situation becomes more complex:

The camera may assume another IP address on its own accord, bypassing the IP filter.
The camera may change its MAC address, so as to avoid any MAC-based filtering on the router.
The camera may try to send data covertly through DNS requests. Indeed, while the router blocks the traffic to the outside world, the camera may still talk to the router, in particular to the DNS server that the router maintains. That DNS server may then relay DNS requests to external entities. Quite a lot of data can be smuggled that way; see this presentation for an introduction on the subject.
And, of course, since the camera is equipped with some WiFi-able circuitry, it may try to talk to other WiFi access points in the vicinity.

So one may say that you will be able to contain the camera traffic to the local network only as long as the camera will try to talk to external servers only for stupid but not deliberately dishonest reasons (e.g. check for firmware update).

As for preventing access to the camera from the outside: again, you have to assume that the camera is not willingly opening a covert channel. When DNS queries carry data, it goes both ways... Let's assume that the camera behaves properly. In that case, you must ensure the following:

The WiFi layer is robust. To make things short, this means WPA2 with a sufficiently random password (see the Wikipedia page on WiFi security as a starter point on the subject). To make sure that the camera is indeed WPA2-able, configure your router to allow only WPA2 and reject WPA and WEP; if the camera still communicates, then it does WPA2 and that's fine. Otherwise, ditch it.

In any case, leave your router in WPA2-only mode.
The rest of the local network is robust. The router will act as first protection layer in this case; external packets will reach it, not other machines. You will configure the router to forward connections to port 22 to a specific local IP address, assigned to your Linux server, and that server runs a SSH daemon on that port. Make sure that security updates are applied regularly on that server; you don't want a remotely exploitable hole in the SSH daemon or the kernel to allow an intruder to hijack it.

A corollary is that some malware on any client machine connected to the local network can open doors and give access to outsiders. You should think twice before allowing friends to "connect to your WiFi" with their own devices, whose cleanliness you cannot ensure.

Another corollary is that everything relies on the absence of remotely exploitable vulnerabilities in the router itself. This might be a bit optimistic...

If you really want to be sure, do the following:

Don't use a WiFi-able or even network-able camera. Use an USB-based camera, connected to a PC running Linux (e.g. your server). That machine will receive the feed. Now the problem becomes one of controlling what that Linux system does, and that's at least doable without too many assumption on the behaviour of closed-source firmware and drivers.
Put a dedicated router/firewall between your WiFi router and the router provided by your ISP. That dedicated router should be, again, a small PC running some Unix-like system. The idea is not that Linux would intrinsically be better than the OS inside a normal, cheap router; indeed, some of them actually run a Linux kernel too. The point is that, with a PC, you can apply updates on a daily basis, whereas firmware updates for routers are rare, when they exist at all.

The whole underlying idea is that you can get decent security, as long as you spend system administration time on it, and security updates can be applied at all.


Instant access to application using token in url

This could be done (relatively) safely, but you have to watch out for a few things.

First, you should make sure nobody can access the token from another person easily (doh!). This is harder to do in practice than it seems. For instance, if you are emailing the token in plain text (which you will), you are basically passing the token from smtp server to smtp server you have no control over. EDIT: but the same would also hold for one-time tokens. Using SSL on your server is also a good idea, as that will encrypt the request headers that include the secret string.

Secondly, you should make sure the key is long enough for brute force attacks to take too long. If you combine this with brute-force-detection on your server (the hiawatha webserver can do this out of the box) you should be pretty safe against these.

Third, make sure the key is random! If you are using microtime, this means that an attacker can make an educated guess on the registration time of the victim (most websites have some sort of "registered at" feature), and just test all hashes from timestamps around that time. This reduces the number of hashes to test (for a single, targeted user!) from impractically large to just one million. That might seem a lot, but with one PC, and a 100ms response time this only takes a day. Remember, this is a targeted attack, which makes this very dangerous.

Another option you might implement is to use both the hash of the username, and the access hash in the URL. This way targeting every user at once is not possible.

IMO, when these things are taken into account, getting a token based login can be safer than a "regular" login, where people choose bad passwords and write them down on pieces of paper on their desk.


Does gmail still ignore DKIM if SPF passes, DMARC style?

That article mentions a new "security warning" in which:

On the web or Android, if you receive a message that can’t be authenticated with either Sender Policy Framework (SPF) or DKIM, you’ll see a question mark in place of the sender’s profile photo, corporate logo, or avatar.

This has nothing to do with accepting a message for delivery. All it means is that, when neither DKIM nor SPF pass (presumably with alignment), the image used to represent the sender will be replaced by that gray stop-sign with a bold red question mark on it, as demonstrated in the screen shot.
This was an early attempt at something like BIMI (though in the other direction; this is an image to warn of potential spoofing rather than an image that is robust against spoofing) and I think it's a good protective step.
As of 2016, Google and many others block mail when DMARC invokes its reject policy, so this only affects senders that do not use DMARC p=reject (which can only trigger when neither SPF nor DKIM passes with alignment).
Back before DMARC, SPF was widely deployed and its use of -all and ~all had very low efficacy; blocking based on either would result in blocking vast volumes of legitimate mail. The SpamAssassin community even concluded that ~all (soft fail) was a stronger spam indicator than -all (hard fail)!
Without DMARC, senders don't see when their mail fails to properly verify with DKIM or SPF (barring RFC 6652, which I've never seen used). They therefore cannot determine if their failure condition (spf -all) works (and DKIM doesn't a failure condition) and neither has a suggested failure policy. DMARC provides the reporting mechanism to determine what issues may arise with a blocking policy and then lets senders issue such a policy.
If you want to require DKIM, I suggest an SPF record of v=spf1 ?all so that SPF can never pass (nor can it ever fail). Then your DMARC p=reject can deny any mail purportedly from your domain unless it passes DKIM. At that point, SPF isn't necessary (DKIM is really hard to replay and basically impossible to forge).


How you plan to use the information is the greater tell of how to handle this. If you're attempting to ensure the nobody is using and SQL injection attack against you, the answer isn't to try and detect it with blacklists. The proper approach is to make use of features such as bind variables.

If your goal is to provide a warning system for somebody poking around at things they shouldn't, detecting SQL keywords such as "and, or, select, delete, where, update, drop" and the like can help. The problem with blacklisting ( SQL query sanitation (black list) ) is that two-fold: you will probably get false positives and you will probably miss well-obfuscated attacks. While it can give you an edge in attack detection, I've written queries that get beyond these filters and I've become very frustrated when normal sentences are blocked when filling in forms.


For Javascript, Internet Explorer allows you to block that specific functionality, without disabling Javascript altogether.
In Tools -> Internet Options -> Security ->  -> Custom Level, you can find the following setting:

Sadly, I wasn't able to find an equivalent setting in neither FF nor in GChrome.

Additionally, however, as it has been mentioned, there are other ways besides Javascript for a browser/webapp to access your clipboard. Some have some forms of controls available too, but I'm not familiar with all of them (e.g. Silverlight has CAS, but I dont know SL well enough to know how to block it).


Why use .ENV? What's wrong with storing secrets in a config.php file outside root directory?

To clarify, the security and flexibility are gained by putting secrets into environment variables.

.ENV is a convenience and, ideally, is not used in production.  Many hosting services will handle deployment for you, and provide a way to store production environment variables securely, without .ENV.

Putting secrets and configuration in environment variables is about mitigating the damage of more common breeches, eliminating classes of mistakes which can lead to security vulnerabilities, and making deployment simple and flexible.

Secrets are put into environment variables so they never touch disk when deployed. Only the server process and its children have the secrets. This mitigates the damage if an attacker...

gains read-access to your production server's filesystem
gains read-access to your code
can execute code, even your code, on your production servers

To get your environment variables, the attacker must be able to alter code on your production server, or inject it into your deployment process. If someone can inject print_r into your production, or if you forgot to delete phpinfo.php, a great many things have gone wrong with your release procedure.

Practical security is layered. If one layer is breached, the rest are still secure. If an attacker gains access to your filesystem, they don't have your secrets. If you're worried they'll alter your running code, put your code on a read-only filesystem.

Configuration is put into environment variables to simplify deployment. One does not need to have separate config files for development, and testing, and staging, and production, and each customer. Instead, each deployment sets its own environment variables.

If you're following Point 10 of the Twelve Factor App, different environments and deployments should have few differences.

.ENV is a optional compromise for convenience. Developers will be running bits of code in many different environments, and remembering to set environment variables in all of them get tedious. Tedium breeds mistakes. So it's better to have a fairly secure process, and all the secrets in a single location.

Development machines have different attack surfaces than a production machine. For example, they can be stolen. One of the important security layers is to ensure developers use an encrypted filesystem, encrypted virtual memory, and screen locks; if their machine is stolen, the information on the disk is safe.

Even so, .ENV should not contain production secrets. Developers should be using development databases and accounts.

If .ENV is used for deployment, then it should be encrypted. Then one must only secure a single, per-developer key which is put in, you guessed it, an environment variable. Rails Encrypted Credentials uses this approach.

  Is there anything particularly wrong with the good old config.php stored outside document root?

There are many disadvantages.

First and foremost, your secrets must live on your production server's disk. Anyone with read access to that file now has your secrets. Putting it outside document root is little protection, there are many security vulnerabilities which allow access to files outside document root.

config.php is code and is vulnerable to additional classes of attacks that a data file is not.

config.php can get large and complex making it difficult to tell which parts are secrets and which are not. This makes security audits difficult.

config.php requires putting your secrets on disk. .ENV is optional, you can develop and deploy using only environment variables.

config.php can easily find its way into the code repository.

Each deployment needs a slightly different config.php with different secrets making deployment more complex.

In contrast, .ENV is a small, simple data file with a single purpose. Your QA and deployment process can automatically detect if .ENV slipped in, or if it is unencrypted. There is a single, simple data file which needs to be changed between environments.

And .ENV is entirely optional.

  I mean you could put that in git ignore too and it's not going to be
  part of your code at all.

config.php is code and should be tested and version controlled. Not having it as part of your repository complicates deployment. This is point 1 of the Twelve Factor App. .ENV minimizes the compromises to your development process. And, unlike config.php, it is optional.

  There are also other ways it could leak (e.g., logs).

You are correct that logging is a potential security leak. That doesn't mean we give up.

You can set different log levels in development vs production using, you guessed it, environment variables. Production log levels would log less and be more careful about what is logged.

You can add a scrubber to your logging function, there are many available, to remove any sensitive information before it is logged. Some look for common patterns such as passwords in URLs, credit card numbers, and PII. With all your secrets in .ENV your logger could automatically remove secrets with a simple regex.

And rather than logging to a local file, you can also stream your logs to a logging service. This is point 11 in the Twelve Factor App. Now your logs are off-site; your production server can be compromised but your logs are still safe.

The Twelve-Factor App takes some getting used to. PHP is an older language with more traditional ideas and may require more adaptation than other languages. I've been following it for a couple years in Ruby. It's made a marked improvement in the speed and reliability of my processes.

And I hope now you understand why Environment Variables Considered Harmful for Your Secrets is itself harmful. The author is concerned about exposing secrets to child processes, a valid concern, but then advocates putting those secrets on disk; a far broader exposure. And since child processes are run by the same user as the parent, the child processes can see the secrets file anyway.

If you truly don't want to store any secrets locally at all, look into Vault.


Breaking mysql username and password form

The second version of the website escapes single quotes to two single quotes.
Is there a way I can log in as the user hello_world?

Yes, because this kind of protection is not secure at all (I also would not call it escaping).
Attack
Imagine an attack like this:
Username: hello_world
Password: \' OR 1=1 #

Which would be transformed to:
Password: \'' OR 1=1 #

Which would probably look like this in a query:
SELECT * FROM users WHERE username='hello_world' AND password='\'' OR 1=1 #'

Which is then executed like this, because the comment (#) cuts of the rest of the query:
SELECT * FROM users WHERE username='hello_world' AND password='\'' OR 1=1

So it checks if your password is \' or if 1=1 (which it does) to authenticate the user hello_world.
Further Damage
Note also that login bypass isn't the only attack that can be done here.
Data can also be retrieved via blind SQL injection (true = logged in, false = not logged in):
SELECT * FROM users WHERE username='hello_world' AND password='\'' OR ascii(substring((SELECT password FROM mysql.user LIMIT 0,1),1,1))<100
[ etc. ]

It is a noisy attack on a login page, but still, it could cause serious damage.
Prevention
Filtering is the worst kind of protection against SQL injections. Escaping (eg via mysqli_real_escape_string) is better, and using prepared statements is best (they are harder to mess up than escaping).


How to properly invalidate JWT tokens and sessions in this use case?

You can't rely on the client code
General rule of thumb: once you send code down to the client to run on the user's machine, it's not your code anymore. The only security you can count on is security that's enforced by the server.
Stateful vs stateless
When designing a JWT mechanism you have to choose whether you want the server to track sessions in some sort of cache or not
Pros of stateless:

JWT is entirely self-contained; everything the server needs to know about the user and session is contained in the JWT (either a signed JWS if the contents are non-sensitive, or an encrypted JWE if the contents are sensitive).
Low server memory footprint (no cache) and latency (no db lookups).
High horizontal scalability because there is no cache to syncronize.

Cons of stateless:

No way to revoke a token -- the JWT will be valid until it expires (for example, no way to robustly do a logout mechanism).

Hybrid solution: short-lived JWT with Refresh token
The best-of-both-worlds solution that I like is to issue sort-lived stateless JWTs (expires in 5 - 15 mins), and also issue a long-lived stateful Refresh token (expires in weeks - months). That way the flood of API requests that happen on page load are using the high-performance stateless token, but you get to enforce logout every 5 - 15 mins when the client needs to trade in its Refresh token for a fresh JWT and Refresh token.
Auth0 has a nice writeup of this solution here:

https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/


Is there any need for PBKDF2 with AES when using a uniform key space?

If you have a 128 bit secret random value (or 192 or 256 bits for AES-192 or AES-256), then yes, you can use that as an AES key without running it through a key derivation function.

However, the example you provided does not contain random bytes, it contains (presumably) random characters from a certain character space with at least 56 characters and probably not more than 100. A truly random byte will have one of 256 values with equal probability, whereas a byte in this secret has one of 56-100(ish) values with (hopefully) equal probability.

It is also not 128, 192, or 256 bits. It is actually 128 bytes, which suggests to me that someone may have misunderstood what key size they needed, and generated it incorrectly.

If you try using the secret directly as a key, likely one of three things will happen:

The software already does its own key derivation (not necessarily a slow key derivation like PBKDF2, but some sort of key derivation). Since the key (hopefully) contains significantly more than 128 bits of entropy this is fine.
The software will warn you that the key isn't the correct length and fail.
The software will truncate your key to the correct length and use it. This can be very bad in some cases, but sadly it does happen.


This is possible thanks to OLE (Object Linking and Embedding) technique. It  is intended to share information between applications that run on  Microsoft Windows operating system. Mainly, it allows to embed objects in documents.
Official Microsoft Documentation explains the benifits of OLE. But as any other concept, it could be used for a neferaious intention.

Maybe the easiest way to explain this is the figure below: by dragging  and dropping the executable icon of Notepad on an opened Wordpad file and saving, the double-click on the Wordpad file will lead to open the Notepad application. The figure below explains better the idea:

You can save the document in .txt format. It will look as a normal benign file. However, if you check its properties, you will find its real extension is SHS. You can imagine adding any commands to the file: such as formatting some disk partitions.