Can a large corporation make a believable promise

However, if the third party makes a secret copy, then they can covertly sell it for large amounts of money.

The thing about this is when it comes to a pivotal and highly-valued asset such as said key, it should never be,

created
transmitted
kept
deleted

by a third-party vendor. These processes if possible should be done internally.

Let's say if you would want to task a third-party vendor to delete said assets, it should be done with automation and limit that human/employee interaction, or keep it to the bare minimum.

Another solution would be, another layer of encryption on this already encrypted key. So that even if the vendor would to lay their eyes on this key, it wouldn't mean much to them, only your organization can see it, but this kinda deems the purpose of the third-party vendor a tad bit redundant.


Using AD authentication in a publicly accessible webapp

Besides the very basic rule of "don't store credentials in configuration files"...

I'm not entirely sure what the development team was thinking, but you can use Forms Authentication with SSRS: http://technet.microsoft.com/en-us/library/ms152899.aspx.

It is a pretty hairy design, especially if its designed to continue using SQL to store the users.  Now, migrating to using AD for all users, and letting the currently logged in user access SSRS with the given token is a pretty standard architecture.  That way you don't ever store credentials.


Does Perfect Forward Secrecy (PFS) make Man-in-the-Middle (MitM) attacks more difficult?

Not really. PFS means that if an attacker obtains your private key in the future, they cannot use it to decrypt recorded communications in the past. They can still use it to impersonate you ("you" being your server) if they have a MitM position. This allows them to record and/or modify all the plaintext.

Without the legitimate server's private key (or a fraudulent certificate for said server, and said certificate's private key), MitM on a TLS connection is pointless (aside from certain attacks against bugs in the TLS implementations). PFS makes no difference here.

Now, PFS does matter for forward secrecy of encrypted data obtained through passive recording. MitM is definitely a way to obtain that recording - your ISP could do it, for example, since they always have an MitM position on you - but it could also be done via passive eavesdropping without actually being in the middle of the connection. Examples includes wiretapping, connecting to a hub (not a switch) and putting your network interface in promiscuous mode, monitoring an unencrypted WiFi network (capturing all traffic transmitted), and so on. If your attacker is doing anything like that, either from an MitM position or not, PFS is relevant because it means even if they later get the server's private key they can't decrypt the recorded TLS traffic.


Concerns discussing 'illegal' activities in a job interview

Unless you are undergoing a polygraph examination (in which case you will have already disclosed pertinent answers such as 'have you hacked a system' and are merely being tested on truthfulness of your disclosures) then take the American attitude of anti-self incrimination (the 5th Amendment to the US Constitution).

During your interview, simply explain that you have researched x number of active vulnerabilities and are working with those clients to path their systems (or whatever you SLA with the 'researched into' companies is).

If you have indeed verified the XSS bugs and the companies have patched them, then look into disclosing them completely or at the very least look into having the companies you did the pentests for write you a recommendation letter confirming that you did the work.

Also, there is a distinction between legality and morality. The concept of what is legal and illegal is rather cut and dry (although judicial systems still debate this) whereas the sense of morality is highly subjective.


Why should we sometimes use --+ instead of -- in SQL injection to comment the rest of the query?

From the documentation:

  From a --  sequence to the end of the line. In MySQL, the --  (double-dash) comment style requires the second dash to be followed by at least one whitespace or control character (such as a space, tab, newline, and so on). This syntax differs slightly from standard SQL comment syntax, as discussed in Section 1.8.2.4, “'--' as the Start of a Comment”.

(emphasis mine)

Many URL decoders treat + as a space.


Broadly speaking, the difference appears to be that one server would treat any requested (or at least uploaded) file as PHP code - at least if it actually contained PHP code - while the other treated the uploaded file as an image when you requested it so you had to find another way to make the server treat it as code instead.

The first site was willing to treat an uploaded file as code, even though it was only supposed to be an image. For whatever reason - maybe it checked the file with libmagic, maybe it stored it in a directory assumed to only contain code, maybe something else - when you requested the file the server parsed it as code and executed it, rather than treating it as an image and serving it as static content.
The second site had a much less "toy-like" vulnerability. It didn't treat the uploaded file as code when a user simply requested the file; I imagine if you tried to request it you simply got a response with Content-Type: image/png and the actual content being the uploaded PHP code? The server didn't try to execute it, because it (incorrectly) identified the file (possibly by extension, possibly by some other means) as an image. However, the server also had an additional vulnerability, an attacker-controllable local file inclusion. The include function in PHP treats any specified file as PHP source, loading and executing it regardless of the extension. Thus, although you had to request for an actual PHP page (index.php) to invoke the PHP engine, you were then able to tell it "hey, treat this 'image' I uploaded as source code too" and gain code execution on the server.


How do you guarantee that you don't lose a keyfile?

I think your requirements conflict - plausible deniability is not something which you will get from keyfile backups.

But for the backup/availability, follow standard backup and availability practices - mirror to secure location, secure backup, test backups regularly...


Why is this response splitting attack not working?

The basic piece of HTTP Response Splitting (HRS) that gets left out most often, is the proxy.

HRS is not an attack between a webserver and a browser, or even a browser and a webserver.
The attack is on the idiosyncrasies of semi-compliant HTTP devices, namely, the web server and the web proxy.
Specifically, the attack takes advantage of the fact that the webserver sees one set of responses (one response), and the proxy sees a different set (two responses), and the proxy splits one request to the victim, and the other to the attacker (or the ether).

So, to best test this attack, you would need to set up:

web server
proxy
victim browser
attacker client (or browser)

I am assuming that you missed the proxy part...


key usage attributes and enhanced key usage attributes overwritten with CA template properties

As Crypt32 mentioned in the comments, the enhanced key usage as well as other certificate attributes need to be configured in a template on the Microsoft CA server for a particular signing certificate.

By design, the CA will ignore attributes and extension that are not configured for a template.

Here is a thread on a similar topic for reference. An extract of the key point is listed below.

  ...The Web Server certificate template has a specific Key Usage
  configured, and you cannot override it during a request. As stated
  earlier, someone with privileges in the network will have to duplicate
  the Web server certificate template, and set the Key Usage that you
  wish. In addition, permissions must be set to allow either you or the
  computer account (you are not clear on where this is going) the Read
  and Enroll permissions.


Single quotes are allowed by RFC 5322 to allow for people's names that have single quotes (e.g. Peter O'Toole).

Please refer to:
https://stackoverflow.com/questions/4816424/are-single-quotes-legal-in-the-name-part-of-an-email-address

Unless the server changes its behaviour when you use a certain character, then there is no reason to assume that there is a vulnerability.


Certificate authentication with jQuery's ajax() function

There is no interface to SSL authentication (either server-client or client-server) from JavaScript. It is all dealt with by the browser UI.

On IE, you may be able to use the CertEnroll (previously XEnroll) ActiveX control as a way to get a newly-generated key into the user's keystore; otherwise you would just have to require them to install the certificate themselves.

Either way, when a request is made that requires the client cert - be it AJAX or normal web page access - the browser is repsonsible for using the cert (which may involve popping up a dialogue for the user to pick which cert they want).


Can unwanted software(like spyware) already present detect the user trying to install an antivirus software and go into hiding?

Yes, malware/spyware can indeed detect antivirus software and perform defensive mechanisms. This is a never-ending ‘arms race’ on how and where they hide code.

Fortunately, once a system is compromised there is no 100% accuracy on getting back to a clean slate without wiping the system back to a known good state.

In my enterprise environment, once we have any concerns, we blow the computer's data away and rebuild...

Best of luck!


Is it common to steal plain text passwords and use them to log in to other websites?

It is known as credential stuffing, and it is becoming increasingly common due to the number and size of data breaches in recent years.

You are right to be concerned about password reuse. That, along with high entropy passwords/passphrases, are two very good reasons to start using a password manager.


I ran a netstat on my server and port 80 is listening, does that mean it is open and vulnerable to attacks?

Port 80 is the standard port for web servers. It is supposed to be listening for people to connect to it with their web browsers. That is how it works. All web servers are targets for people to hack, so technically yes, you are open to attacks-- But that is the nature of a public web server. You install things like firewalls and intrusion detection applications to cover yourself when you set one up. If you add SSL, it will be listening on port 443 by default as well.


What are the security concerns with turning off Extended protection for authentication in IIS7 on ADFS?

I think you don't have to disable (ExtendedProtectionTokenCheck=None) extended protection, you just need to make it optional (Allow instead of Require).

This allows to connect incompatible clients without this protection (and vulnerable to MITM) but also allows InternetExplorer to use the additional protection. However there is no way to enforce this on the client, so it gets vulnerable to a downgrade I think.

An idea would be, that you have a special endpoint which allows skipping extended protection but will not be used by regular clients. Then only your alien clients will be vulnerable to the MITM problem. Depending on other factors this might be however not a big risk. If your employees are used to go to lunch without locking their screens you don't have to worry about it :)

MS Documentation is here: http://technet.microsoft.com/en-us/library/hh852537.aspx


How to find IPS events in sonicwall syslog

Silly me.

I had "Low Priority" events not being logged.
For those who might be having a similar experience,
I had forgotten that there were so many events logged (browsing activity, etc...) that it didn't seem warranted to keep the low priority events being logged.  That said, I'm not sure why things like This "IPS Detection Alert: FILE-TYPES-HTTP Image -- JPEG 1A (HTTP Download)" would be considered a low level intrusion, but I'm not a firewall expert.  On the dashboard, they seem to be categorized differently than the Suspicious CIFS that I was looking for in the first place.  I find that a little frustrating and curious, but no point in venting here.

The Suspicious CIFS is considered a Low Priority threat according to sonicwall.com


certificate about to expire, CSR needed?

Your CSR is essentially a wrapper for your public key, along with some identifying information (domain, organization name, locale, region, country etc.) and a digital signature (using your private key, verifiable using the public key that it contains)

The Root CA you're using for signing will determine how many of these fields are really necessary; at a bare minimum a CA will only pull the public key from your CSR, so the answer really comes down to checking with your CA what they need. Most CAs I know of will support a certificate 'renewal' (generating a new certificate that is nearly identical to the existing one, but with a new validity period) from the original CSR. They will also typically allow you to optionally provide a new CSR to change the public key, and either enforce that the other information is the same or simply ignore any differing information in the new CSR.

As an example, Entrust Datacard's retail certificate purchasing wizard pulls the domain, public key, and any Subject Alternative Names from the CSR and discards everything else. The Organization information fields and certificate validity period are populated through their UI.


Will extra rules to my diceware list generation scheme decrease security?

Creating a length 10 string of characters randomly chosen from an alphabet of 7776 unique symbols will have a bit entropy of log(7776^10,2) or almost 129 and a quarter bits.

However as noted by Arnold G. Reinhold, 7776 is a lot of words and you tend to run out quickly when you start to talk about words that you can remember while presumably avoiding risque words when it's a password at work or possibly used to encrypt something you're going to send to someone else.

IMO: Both lists could use some work as typing out 10 randomly chosen words from either is quite the exercise in dexterity, and in practice copy/paste has issues with apostrophes, ellipsis and other annoying punctuations/emoji


Is there a cryptographic function that generates a reconizable visual pattern?

I'm going to ignore the horrible usability issue in this answer and just focus on the title question here.

--

One idea is to generate a visual fingerprint like OpenSSH visual fingerprint. OpenSSH Visual fingerprints produce blotch of ASCII characters that are supposedly somewhat memorable can be quickly compared visually.

If you want to be slightly fancy, there's the Aestheticode. Aestheticodes like Penguin Barcode can be scanned, is distinctive and aesthetically pleasing, and is fairly easy to visually compare without a machine. Problem is that aestheticode are short and most aestheticode are generated manually; you'll need to be able to procedurally generate these images if you're going to do this everyday.


Pen test results for web application include a file from a forbidden directory that is not even used or referenced

Brute force scanners
Many automated scanners get around banned directory listings by "bruteforce" searching for files. This means that they will check for additional files with names similar to files that do exist (i.e. filename.js1 as well as files that aren't referenced at all (aka secret.txt). If you happen to have a file whose name is on the bruteforced list and is in an accessible directory, then it will be found regardless of whether or not "directory listing" is enabled
It's worth pointing out that hackers do this same thing, so this is a real issue. In general, if something is in a publicly accessible directory, then you should assume it will be found. So if you don't want it to be public then you need to keep it out of public directories - disabling directory listing provides very little security.
Real vulnerabilities
Finally, this may not seem like a large issue (and it probably isn't), but leaving backups of javascript files in public directories is actually a bad idea in general.  When it comes to XSS an attacker will generally have the most success if they are able to exploit a javascript file hosted on the same domain.  This is because doing so gives opportunities to bypass a CSP or other security "firewalls".  As a result, if an older javascript file happened to have a security vulnerability in it that was fixed in a later version, and an attacker found a way to force the user's browser to load the older javascript file, they may chain their way to a more damaging vulnerability.  This may seem far fetched, but chaining together many small vulnerabilities into a larger one is how many of the worst breaches happen.

tl/dr: If something is hosted by your website but doesn't have a
reason to be there, then it is a liability.  Kill it with prejudice.


Building software safely for malware-free distribution

It's important to think about what kind of threat you are trying to protect against. Your questions could be taken to imply two different threat levels:

A general virus that just injects itself into any executables it happends to stumble over.
Malware designed specifically to infect your build process and embed itself in freashly compiled executables.

To protect yourself against the first category, schroeder has a good suggestion - just check the filesize. Your compiler probably already outputs that. Or have your compiler output a hash and use that, or sign the file in the build flow.

If you are up against a theat of the second type, the above is no good. If the attacker is sofisticated enought, nothing can help you at that point. As soon as your system is compromised, you are owned.

In the end, it comes down to how advanced threats you want to protect yourself against. Using a separate machine could help, and so could a VM (or a "trusted third party", even though I am not sure I would trust one). But a sufficiently advanced attacker could overcome those obstacles as well.


There are two choices for the attacker to make the request to sendmoney.php to generate the token. Case 1: the attacker does it from the victim's computer using the victim's credentials. In this case, the browser's built-in protections will prevent the attacker from reading the generated token, so they can't send it along with the form. Case 2: the attacker does it from their own computer using their own credentials. In this case, the token won't be valid if submitted with a form bearing the victim's credentials.


If a website has a 5 second time delay before showing the login form, is that likely a security measure?

Is the homepage implementing some sort of security measure?

If you are referring to https://www.chase.com, then nope, it's just slow to load and do the transition thing. Terrible UX maybe, but this is not a security feature. A login cracking bot would not typically use the user interface anyway.

Basically, it's a banking website, and terrible UX is sadly the norm.

While this particular case may not be security related, it's not uncommon to have rate-limiting between login requests. This would have to be implemented in the back-end code to effect all requests to be effective.


Log user out after change of IP address?

If you want to implement a security measure, you need to know what you secure yourself against. In this case, you want to secure yourself against a Man-in-the-Middle attack.

As you said yourself, a change of IP address is not a good indicator for that, for actually two reasons:

There are many reasons why an IP address would change for legitimate reasons, such as the user gaining or losing a Wi-Fi connection, the user connecting to a VPN, etc. As such, this alone is a really bad indicator for an attack.
For the detection to work, it assumes that a user first starts a session on their own, and is then intercepted by the Man-in-the-Middle. If your user is already being intercepted, the IP of the Man-in-the-Middle is the only IP you will ever see.

As such, this security measure is rather prone to false-positives and false-negatives, making it rather unreliable.

But there is a security measure employed by Google that works in a similar way. It detects the usual behavior patterns of a user, such as the usual locations and IP address ranges they connect from. Should a login deviate from this pattern, a security alert is triggered.

This is most prominent when users want to check their emails on vacation or similar, but can truly be an indicator of possible compromise if the user's regular usage patterns are clearly established.

This should be an example as to how information from IP addresses (and other sources) can be used to analyze behavior and thus detect anomalies. Anomaly Detection is a field all on it's own, so don't expect a comprehensive introduction in one paragraph. This example should merely serve illustrative purposes.


Framework behind password reset mechanism

Password reset mechanisms typically work like this:

The server generates a secret random string (e. g. 16 bytes read from /dev/urandom).
Then the server sends this string to the user, often embedded within a link to a password reset page. A hash of the string is stored in the database for later validation. Usually, the string is only valid within a certain time frame.
When the user clicks on the link, the server checks the transmitted string. If it's valid, the user may change the password.

While this approach is very common, it's obviously far from perfect. A plaintext e-mail may very well end up in the wrong hands, in which case the secret string is compromised. Whether or not this risk is acceptable depends entirely on your application and your specific requirements.


Is it safe to use unencrypted rsync when my backup is encrypted?

Assuming all data to be transferred is encrypted client-side, it should be completely safe in terms of data privacy to use the regular, unencrypted rsync:// protocol. If the credentials used for authentication are also sent in the clear, then an attacker on the wire may be able to use them to modify or delete existing encrypted files. While proper client-side encryption will detect that files have been modified, files that get deleted by a malicious user will be gone.


Email header of an email sent from one email ID to the same email ID

DKIM headers are usually added by some but not all mail servers for outgoing mail, i.e. mail leaving the domain. SPF headers are added by some but not all mail servers for external mail entering a domain. In your case the mail is only sent from one account to the same account so it probably never passes an outgoing nor an incoming mail server and thus these headers don't get added.


Is it legal to run penetration testing tools against google, facebook etc..?

Legal or not, it would not be any useful for them, and certainly wouldn't help you getting any reward. You get a bounty by finding something new. The sites offering bounties are probably already tested using automated tools.


Is there a way to find out what information website queries about us?

No, there is not. While fingerprinting can be done by actively providing the browser with a resource that will allow for fingerprinting, it is also possible to fingerprint a client entirely passively. For example, the specific order that client headers are transmitted in gives away the web client you are using. Even if you spoof various headers like accept encoding and user agent, you are still giving away the order of the headers, which itself makes passive browser fingerprinting possible. Another example is analyzing the behavior of the client when fetching resources. In what order does it fetch resources? How many does it fetch in parallel? All of this data is routinely sent to any web server you connect to, and there is no way that you can tell if it is being used for fingerprinting purposes.

It is possible to detect if certain explicit and active fingerprinting attempts are made, for example AudioContext fingerprinting or, as you provided as an example in your question, WebGL-based fingerprinting, but detecting this will not allow you to conclude that the website is not engaging in fingerprinting activity. In addition, there are going to be numerous ways to covertly collect this information in a way that looks quite innocent to automated detection. As for specific software that is able to do this, explicit software recommendations are off-topic here (and I do not know of any specific pieces of software that can detect this, anyway).

You may want to check out AmIUnique, a proof-of-concept website that uses a variety of fingerprinting techniques, both active and passive, to uniquely identify a system. It uses not only primitive techniques such as UA fingerprinting, but more advanced techniques such as WebGL and AudioContext fingerprinting, font enumeration, browser window dimensions, etc.


Can back up servers be used to defend against DDoS?

Maybe. It depends on whether or not you have a single point of failure that is the target of the DDoS.

If you have a domain, an IP, an ISP, and a server farm all serving your business, and this gets attacked, then, standing up a new domain, IP, ISP, and server farm will help to mitigate the attack, as long as the attack does not change to target your new location.

If you do not change all those things, like the domain, then the attack could automatically switch over to the new IP, ISP, and server farm once you redirect the domain to the new location. Same thing for each element.

So, yes, given the idea that a DDoS attack is limited in scope, then yes, setting up resources outside that scope could work (until the attack retargets).  But, any single point of failure could bring your mitigations down.


Is there any reason to enable "Windows Update" if you do not connect your computer to the network/internet?

For development machines, it is not uncommon to turn off updates so that you have a stable environment to test on ("what?!?! .Net got updated?!?!). If it is isolated and you control what connects to and is loaded on the machine, your risks are low. That said, I'd still want to have some sort of 'refresh' process to regularly reset the machine to a known-good state, in case some form of infection occurs.

This means, though, you need to really, really control the computer. Like, make sure you scan the files you want to transfer before transferring, etc.

As for malware transferring to another machine: if the malware gets installed on the first machine, then sees that it can't exploit the machine, do you think it just deletes itself? There are many types of malware that look for new machines on the network, or any new connected devices to transfer to. They are called worms.


Have hardware trojans been seen in the wild?

Perhaps this one about a Siberian pipeline, but I'm sure it fits in the "hardware trojan" you're asking for.

Edit:

Does hardware backdoors also fits your search? If so, some more few examples:

HP storage hardware with a backdoor
Cisco and other routers backdoors to allow judicial interception of data
FBI afraid of backdoors in counterfeit cisco products
virus inside a USB picture frame
some political discussion about having trojans in components manufactured "overseas"

And I was unable to find links to the information I gave below, so I'm leaving it as it is, but I can't remember the source or find it again.

Onde I read something about US selling a faulty DEC chip, which would give wrong math, to the Russians, using some canadian company. I'm unable to find any page about it, I'll keep searching.


If using a different password for every application is considered good practice, why is using a directory so widespread?

It is true that if your password is compromised, your access to all other systems in the directory goes with it. However, there are other differences that make the practise of password reuse a completely different ball game:

Directory: Once the breach has been reported, the account can be disabled or the password changed from a central location.
Separate applications: The account would need to be disabled or the password changed per application.
Directory: The breach will not be spread out over systems controlled by different entities - You would just usually need to contact your sysadmin.
Separate applications: You would need to contact potentially hundreds of different companies in order to regain control of your accounts with potential for accounts to be missed.
Directory: Any password guessing attacks over different systems in the directory would most likely to be detected.
Separate applications: If it is known that you possibly use the same password over different accounts, then an attacker could split their attack and try different word lists against different systems undetected until they gain entry.


When using https but not DNSSEC, under what situation, a client is vulnerable?

Properly used https can mitigate the risk of not using DNSSsec because it is checked if the endpoint is the expected one by validating its certificate. Also, the data transport itself is protected. There are several things which can go wrong with https itself (weak ciphers, errors in validation process, too much trusted root CAs with same rights....) but if we assume that all this is handled properly (which is often not) https will give you the following protection:

You talk to the correct server.
The traffic between browser and server is protected in transit against sniffing and modification.

That's all you get.

Notably absent are protections against attacks caused by insecure web applications or bugs or design errors in the browser, that is CSRF, XSS, exploits using Flash, Java, Silverlight, ActiveX, include of 3rd-party code by the site you visit (i.e. social networks, tracking, advertisements...) and all the other typical attacks in today's web. And https will also not help if your computer is already compromised by malware or some security or helper software which does more harm than it helps.


Starting point for Mobile Device Security particularly in a MDM setting?

Check out Dark Reading. They have quite a few blog entries about this sort of thing and they offer daily and weekly e-mail subscriptions (They'll also sign you up for subscriptions to some of their partner publications). Not all of it on Dark Reading is news, and a bit of it is white papers you have to log in in order to download. Overall they've had some nice exploits and solutions over the years.

Slashdot Mobile has security topics relating to new tools on the market. It's community fed so sometimes people do not post things that are available in more main stream locations.

Also pick up a subscription to the 2600 Hacker Quarterly (available on Kindle also). They have mobile hacks from time to time and give walk-thrus on how they're being done. Also they list exploits and the whys of the vulnerability.


“Encrypt and wipe” procedure on Android Lollipop?

You're making the common mistake of asking the wrong question: “is this system secure?” instead of “is this system secure in this scenario?”.

Google's choice to not encrypt unused space makes perfect sense in the typical usage scenario where a user decides to encrypt their data, and all their current and future data is encrypted. The choice not to encrypt unused space has only minimal security impact in this scenario: on a young device, it reveals how much space has been used. Eventually, as blocks are allocated and freed, all blocks will end up encrypted, making it impossible to tell which ones are currently in use and which ones are merely formerly in use.

Data that was stored on the device but is no longer accessible is not encrypted by this procedure. This is a reasonable design, since this is an encryption feature, not a wipe feature.

You can still leverage the encryption feature to make a wipe feature by first turning on encryption, then filling the partition with data — any data. For example, if you have root shell access, cat /dev/zero >/data/zero && cat /dev/zero >/cache/zero && rm /data/zero /cache/zero after turning on encryption will wipe the free space on the partitions containing /data and /cache. Refer to your favorite Android experts for how to accomplish this without root access.

Note that even pre-Lollipop, calling the procedure you describe “encrypt and wipe” is a misnomer. If there was a true wipe, encryption wouldn't be useful, the data would be gone anyway. It's really “encrypt and reset”, where the reset makes data inaccessible through normal means, but not wiped.


Password Hashing: add salt + pepper or is salt enough?

In some circumstances, peppers can be helpful.
As a typical example, let's say you're building a web application. It consists of webapp code (running in some webapp framework, ASP.NET MVC, Pyramid on Python, doesn't matter) and a SQL Database for storage. The webapp and SQL DB run on different physical servers.
The most common attack against the database is a successful SQL Injection Attack. This kind of attack does not necessarily gain access to your webapp code, because the webapp runs on a different server & user-ID.
You need to store passwords securely in the database, and come up with something on the form of:
$hashed_password = hash( $salt . $password )

where $salt is stored in plaintext in the database, together with the $hashed_password representation and randomly chosen for each new or changed password.
The most important aspect of every password hashing scheme is that hash is a slow cryptographically secure hash function, see https://security.stackexchange.com/a/31846/10727 for more background knowledge.
The question is then, given that it is almost zero effort to add a constant value to the application code, and that the application code will typically not be compromised during an SQL Injection Attack, is the following then substantially better than the above?
$hashed_password = hash( $pepper . $salt . $password )

where $salt is stored in plaintext in the database, and $pepper is a constant stored in plaintext in the application code (or configuration if the code is used on multiple servers or the source is public).
Adding this $pepper is easy -- you're just creating a constant in your code, entering a large cryptographically secure random value (for example 32byte from /dev/urandom hex or base64 encoded) into it, and using that constant in the password hashing function.  If you have existing users you need a migration strategy, for example rehash the password on the next login and store a version number of the password hashing strategy alongside the hash.
Answer:
Using the $pepper does add to the strength of the password hash if compromise of the database does not imply compromise of the application. Without knowledge of the pepper the passwords remain completely secure. Because of the password specific salt you even can't find out if two passwords in the database are the same or not.
The reason is that hash($pepper . $salt . $password) effectively build a pseudo random function with $pepper as key and $salt.$password as input (for sane hash candidates like PBKDF2 with SHA*, bcrypt or scrypt). Two of the guarantees of a pseudo random function are that you cannot deduce the input from the output under a secret key and neither the output from the input without the knowledge of the key. This sounds a lot like the one-way property of hash functions, but the difference lies in the fact that with low entropy values like passwords you can effectively enumerate all possible values and compute the images under the public hash function and thus find the value whose image matches the pre-image. With a pseudo random function you cannot do so without the key (i.e. without the pepper) as you can't even compute the image of a single value without the key.
The important role of the $salt in this setting comes into play if you have access to the database over a prolonged time and you can still normally work with the application from the outside. Without the $salt you could set the password of an account you control to a known value $passwordKnown and compare the hash to the password of an unknown password $passwordSecret. As hash($pepper . $passwordKnown)==hash($pepper . $passwordSecret) if and only if $passwordKnown==$passwordSecret you can compare an unknown password against any chosen value (as a technicality I assume collision resistance of the hash function). But with the salt you get hash($pepper . $salt1 . $passwordKnown)==hash($pepper . $salt2 . $passwordSecret) if and only if $salt1 . $passwordKnown == $salt2 . $passwordSecret and as $salt1 and $salt2 were randomly chosen for $passwordKnown and respectively $passwordSecret the salts will never be the same (assuming large enough random values like 256bit) and you can thus no longer compare password against each other.


Why does Google prefer ECDHE-RSA-AES128-GCM-SHA256?

AES-128 is not in practice weaker than AES-256. AES-128 is sufficiently robust that it won't be broken through exhaustive search on the key (see this answer for some details), and an algorithm cannot be "less broken" than "not broken", so there is no additional benefit for security from cranking up the key size to 256 bits.

(There are benefits for marketing, though: longer keys can woo the non-technical minds.)

On the other hand, there is a practical disadvantage to using AES-256: it uses 40% extra CPU when compared to AES-128. This may matter for a server that has very fast network connectivity (say, 10 Gbit optic fibre) or has a feeble CPU. I suspect Google's SMTP server is of the former kind: powerful, but handling lots of incoming data.


What is the difference between Trusted boot and Kernel Patch Protection (PatchGuard)

Question 1:
Kernel Path Protection is focused on the the protection of the Kernel, this means that device drivers cannot modify anything related with the Kernel. If Kernel Path Protection is enabled, you have lower chance of getting any BSoD or that rootkits will be nested into the kernel.
Trusted Boot is more focused on the software that is trusted by the manufacture. So no other programs will be started, like malware.
Both are 2 different kind of methods to protect the system.
Question 2:
Secure/trusted boot is on every system available.
Hopefully I have answered your question.


RKHunter and CHKRootkit Warns About /usr/lib/pymodules/python2.7/.path

Most probably false positive (depends of its content). Got the same warning on two different clean machines (Ubuntu 12.04 & Debian 7).


Trojan detected in windows 10 can it affect dual boot Ubuntu

I can't say what any individual malware (Trojan or otherwise) might do - nobody can, without analyzing it - but the answer to can it is "Yes unless it lacks permissions". However, it probably didn't, even if it could have.
To modify a dual-boot Ubuntu install from Windows, you'd need one of these to be true:

You have the relevant file system driver installed on Windows (Linux, including Ubuntu, almost always uses different file systems than the ones Windows prefers, but both have optional drivers for the other) and have the Ubuntu file system mounted (for example as drive "L:" for Linux). Then the question would be "what permissions are required to access the mapped file system"; if the malware has them, it can do that.
The malware installs the relevant file system driver, and then mounts the Ubuntu file system and accesses it. This requires Administrator permissions on Windows, since you're installing a kernel-mode driver, but it the malware has those privileges it can do anything it wants to the machine.
The malware opens the Ubuntu partition(s) directly as (a) block device(s) - effectively accessing your entire Linux installation as one or more giant files - and tampers with their bits without bothering to go through the abstraction of a mounted file system. This (opening a disk partition directly) also requires Administrator permissions, although once the "Direct Access Storage Device" HANDLE is open, a process can use it to make arbitrary changes without worrying about file system security on that storage device (because it bypasses any file system entirely).
The malware could modify some lower-level component of the system that is used by both OSes, such as the bootloader (one bootloader typically chains to the other, so there is at least one place that could affect both systems), the BIOS/UEFI (system firmware that is present on the motherboard), CPU microcode (firmware present in modern CPUs that controls their behavior), or firmware for other devices such as the hard disk/SSD (practically every hardware component of a modern PC has its own tiny processor running its own firmware, and that firmware controls how the component operates). In all cases this would require Administrator rights, and in some cases there may be additional protections (such as requiring the computer be rebooted a special way or the firmware needing to be signed by a trusted publisher).

So, does this mean your Ubuntu install is totally hosed if that malware did, in fact, have Administrator privileges? Probably not. Most Windows malware wouldn't know to look for a Linux file system, and wouldn't know what to do with one if it found one. It might notice a mounted file system and access it, but the impact is likely to be limited (for example, it is unlikely to know where Linux software stores its credentials, and thus if it's trying to steal them it wouldn't find any). You shouldn't count on that, but the actual risk is low unless this malware was written by somebody who was specifically targeting machines like yours, or the malware is in general known to be damage Linux systems too. It also might just make the Ubuntu installation unusable, perhaps by accident, if it does something like overwrite some part of the bootloader and prevent loading Linux.


Is it safe to store VeraCrypt or TrueCrypt container inside RAR - could this method corrupt the file?

Yes, this is risk free. Not using compression (as you plan to do) helps speed up the process as encrypted data cannot be compressed. However I would suggest you do not use an extra password. Any extra password you need to memorize would be much better put to use extending your VeraCrypt password with it. Otherwise, having multiple layers of encryption allows an attacker to attack one at a time, rather than being limited to attacking it all at once. The only reason you might want to encrypt the archives is if you do not want an attacker to even be able to suspect that an encrypted VeraCrypt container is present. If this isn't part of your threat model, there is no need to use more encryption.

I am curious why you have any  need to split up a VeraCrypt container, though. Obviously in order to use it, you must concatenate the parts. This makes me wonder if you are trying to upload it to a file hosting service which may limit the maximum size of each individual upload. If this is this case, I strongly recommend you do not do this. Hosting any encrypted container that uses XTS mode on a remote server which may be able to see snapshots of the container over time is very insecure.


Is there a common best practice for naming public and private PGP keys when exporting them?

While obviously it's very hard to prove a negative, I think that the reason why you have found no such "common best practice" is that none exists.

The key itself doesn't care about its file name. What's more, there are ways to deal with exported keys that don't ever involve any files on a file system at all! Consider something relatively trivial, such as gpg --export 0xDEADBEEF | ssh me@remote-server.example.com gpg --import.

You should however name the exported key file such that you have some idea of what key it contains, since the exported file itself (ironically enough, more so if the file is ASCII armored than if it is not) won't hold that information in a readily readable format unless you edit it in yourself (for example, in the Comment: field of an ASCII armored data blob).

For publication, the hexadecimal key ID is usually a good place to start because it's reasonably unique, particularly if you use the full 64-bit key ID or even the fingerprint (which is practically, but not theoretically, guaranteed to be unique).

For personal storage, or to for example e-mail the public key to a correspondent, you usually want to be able to tell keys apart yourself, but don't really care about global uniqueness. Thus, something that identifies the key to you is likely a good place to start; thus, you might start by looking at information such as the associated name, the associated e-mail address, generation or expiration date, or something along those lines. If you generate a new key once every 18 months, for example, the generation date might be a reasonable thing to include in the file names, because it tells you about the chronology of the keys as well as which you could expect to be used for a specific message.

I have seen a variety of naming conventions to differentiate between the private and public portions of the key, but the bottom line there is that it really doesn't matter at all as long as you can tell with no risk of ambiguity which file is which. If you want to append -private and -public before the file name extension, or if you want to name one .asc and the other .private, or whichever scheme you prefer, really doesn't matter at all: just pick one that makes it obvious to you which file is which.


Show confirmation popup before running any downloaded program in Windows 10

You will have to be careful where you download and store files, but there may be a simple solution.

On your download directory, edit the security settings (right-click, Properties, Security tab, Advanced button) and add a deny entry for execution for Everyone. Do the same for any directory where you would store these files.

Media files are only read, not executed---the player itself is executed, but it executes from its installation directory.

If you download legitimate executable files, you would simply need to move them to another directory where execution is permitted. If you prefer AppLocker, it should be able to restrict execution based on directory paths as well.

A word of warning: Either approach may not work properly or consistently with *.lnk files, as Windows seems to have some weird, undocumented handling for them in some cases. You still need to be careful.


What is the name of this token-authentication scheme?

It sounds similar to OAUTH but the token usually contains basic attributes, including the user identity. You need to make sure that whatever the token contains cannot be modified, this can be done through validating a signature or using an HMAC.

I wouldn’t recommend reinventing the wheel here, just implement OAUTH.


No, another device cannot access your device's files/photos. That would require the other device to browse your device's files.


Credentialed scanning through SSH tunnel

You could instead set up a layer 3 tunnel over SSH and route directly to the windows target (see below link for example).
https://wiki.transmission.ninja/doku.php?id=networking:layer_3_vpn_over_ssh
This would solve the issue of you scanning the linux target as you will be able to scan the windows IP address directly.
You could also use a tool called sshuttle for this, but I find that can be a little buggy sometimes.


By default, does a linksys router log connections?

Logging is disabled by default on LinkSys routers. The following is a quote from the LinkSys WRT54G user guide:

  The Router can keep logs of all traffic for your Internet connection.
  To disable the Log function, keep the default setting, Disable. To
  monitor traffic between the network and the Internet, select Enable.

Routers will generally store the last N connections in a cyclic buffer.


Is it possible to remove the password on new generations of Lenovo X1?

From the Lenovo Support Website:

  A forgotten Supervisor password will prevent access to the ThinkPad
  BIOS setup utility. If the Supervisor password has been forgotten and
  cannot be made available to the service technician, there is no
  service procedure to reset the password. The system board must be
  replaced for a scheduled fee. Proof of purchase is required, and this
  repair is not covered under the warranty.

So this leads me to believe that there is something soldered onto the board that is storing the supervisor password, possibly the TPM. However, I have not been able to find any evidence for this claim. The way to reset the Supervisor password from here is replacing the system board, either by yourself or through Lenovo.


Any attacker who has access to some equipment (cable, router, ... ) between the network modem and the remote server might be able to access the data, i.e. it should not be a problem for government agencies. Note that an attacker might also change the path of the traffic with BGP hijacking in order to be in path of the traffic.


Is it possible to Spoof a TeamViewer ID?

To the best of my knowledge the TeamViewer ID is provided by the TeamViewer servers.  The attacker would have to emulate the entire TeamViewer protocol in order to spoof the ID.  They would have to act as both the TeamViewer servers in the middle, as well as connecting client itself in order to make your system believe that it was a legitimate TeamViewer connection.


Potential added risks of using Docker in production servers

Regarding the point of the good practices for Docker deployments, you can run the CIS Docker Benchmark which performs a set of automatic tests to guarantee that the CIS Docker Guidelines are compliant in your Docker containers.
You can get these guides for free at: https://www.cisecurity.org/cis-benchmarks/

This can give you a good overview of the things you can tweak in your Docker config to improve security and also learn a lot of things that you probably haven't heard before about Docker (at least that was my case).

Also the official Docker documentation has a quite good document related to securing Docker containers. You can find it here:
Introduction to
Container Security

Keep in mind that some of the settings may be quite restrictive (with the impact that this may have) and also some recommendations are based on very new and likely unstable features. Here you have to determine the balance between security/usuability as usual.


HTTPS connection to specific sites fail with cURL on macOS

Root CA certificates used by the mentioned sites (Comodo and USERTrust) have expired this morning (UTC time). While I find it remarkable that two different Root CA certs would expire at the exact same second, this may be explained by USERTrust being affiliated with Comodo (now Sectigo).

Edit: These two actually never were Root CA certificates, but rather intermediate CAs signed by "AddTrust External CA Root". Therefore, their expiration date was determined by the validity of the "AddTrust External CA Root" certificate, which also happens to have expired at the exact same second.

Now, updated certificates (sharing their private keys with the expired ones) have been issued back in 2010 (Comodo, USERTrust). These certificates are part of the common Root CA stores these days (including Apple's system trust store), therefore browsers establish the connections perfectly fine. The same is true for most variants of cURL (e.g. from MacPorts or Homebrew), which are built against custom OpenSSL installations.

The built-in cURL variant of macOS 10.14 is built against LibreSSL and uses /etc/ssl/cert.pem as its Root CA store, which also includes the new certificates. However, something appears to causing cURL or LibreSSL to prefer the old certificates for its validity check. I suppose cURL is at least somewhat involved in the problem, since I couldn't get the connections to fail using /usr/bin/openssl s_client (/usr/bin/openssl is actually built from LibreSSL).

My hypothesis would be that the problem is caused by the sites sending the expired Root CA certificate as part of their certificate chain. Including the Root CA in such chains is allowed, but not required, and in this case appears to break certificate validation.

Edit: This is part of a series of issues around the "AddTrust External CA Root" expiration. See this blog post by Andrew Ayer or this Twitter thread by Ryan Sleevi for the bigger picture. Ryan Sleevi also has a collection of things failing due to the expiration.

On macOS 10.15, where cURL uses OpenSSL 0.9.8 by default, the issue apparently may be mitigated by setting the environment variable CURL_SSL_BACKEND=secure-transport. This does not work on 10.14 with its LibreSSL which, according to Christian Heimes, is affected by the issue in general.


Developing Home Automation Protocol, How to make messages secure?

You are on the right path, but you would need 3 things:

Unlock Message
Timestamp
Unique Message ID

This way the Unlock Message couldn't be captured and replayed in the 30 second window.  You would just need to keep a log of used Unique IDs in D1 that have been used in the last 30s

As long as the private key in H is kept secure, and the public key in D1 is not tampered with ... this method should be secure.

It should also be noted that D1 should have a method of securely syncing its internal time system with H periodically to prevent time drift which could otherwise render D1 completely inoperative.

Another option would be to keep a public /  private key on both H and D1 ... this would allow you to create a shared secret which could be used as a Secret Key for something like AES256 communication between H and D1.  I am noting this because you put TLS as a tag in your question ... and this is in essence how TLS works.

TLS Handshake


Security papers or material focusing on the industrial control systems (SCADA)

For specific analysis of a particular attack in this space you should read the Symantec Stuxnet paper - gives good background as to just how badly a SCADA attack can compromise an industrial system.


Mitigate DDoS attacks by randomly blocking traffic during the period of detection process

DDoS is a synchronous attack from many points. So there are no such things as "finding attacker address and stop them".

If the attack appears to be hijacked IoT(e.g. Mirai botnet), you still has a little chance to denied those IP, e.g. send a little script to make sure it is authentic browser response, e.g. get a canvas, browser plugin. Mark and drop the IP if there is no response. However. this method is useless if the attacking node is overwhelming your server capacity.

So the only mitigation is some sort of ISP services, e.g. Content Delivery Network(CDN), so massive traffics don't hit your server directly. the CDN that promising DDoS countermeasure(which can make use of SDN/firewall/etc) will implement stated process.


You may be having difficultly because it's not a network based interception of http, it's a radio based interception of data at layer 1 (physical).

Essentially, on a wired network:

Layer 1 (physical): Copper or fiber wires and physical devices (NIC, GBIC, switch, router, firewall).

Interception at Layer 1 (i.e. using port mirroring on a switch to direct a copy of all traffic on Port X to Port A(ttacker) is quite simple, but requires physical access at some level (access to the cable in Port A, at a minimum).

Layer 7 (application): HTTP or HTTPS
Once Layer 1 has been compromised, HTTP traffic is completely available.  HTTPS traffic is not; additional protections are provided by HTTPS.

On an 802.11a/b/g/n/ac Wifi network:

Layer 1 (physical): Radio waves being broadcast from one antenna, which induce current in every antenna they're in range on (where range depends on both the inverse square law as well as the receiving equipment's sensitivity, gain, and losses).
Interception at Layer 1 can be done by anyone who can manage to get a "good enough" signal to their receiving hardware.

Higher sensitivity receiving hardware has a lower bar to the "good enough" standard.
Using a poorly designed or implemented antenna (your belt buckle) requires a stronger signal than using a well designed and implemented antenna (a properly calculated antenna tuned specifically for the frequency in use, with a very short run of low loss cable, matched impedance, etc.).

Layer 2 (data link): WPA/WPA2, if enabled, provide protections here by encrypting the payload of 802.11 frames.
Layer 7 (application): HTTP or HTTPS
Once Layer 1 has been compromised, if there is no encryption at Layer 2, or if that encryption has been defeated, HTTP traffic is completely available.  HTTPS traffic is not; additional protections are provided by HTTPS.

Wireshark is quite capable of using a wide variety of Wifi cards in monitor mode ("promiscuous" mode in wired NICs) if the OS lets it, which Linux does much more easily than Windows.

If you want to see this ON YOUR OWN WIFI NETWORK ONLY (see local, regional, and national laws in your location), try a Kali (previously known as Backtrack) LiveCD.  Or buy an AirPcap wifi adapter.  Or use many USB Wifi adapters in a Linux (Kali or other) guest OS in a VM on your Windows host.  Use either Wireshark or Airodump-ng.

For Wireshark, further details are available at the Wireshark CaptureSetup/WLAN page.

For Airodump-ng, part of the Aircrack-ng suite, information is available at pages like the Aircrack-ng FAQ "What is the best wireless card to buy" page.


Avast AV could read Firefox saved passwords

Passwords saved by Firefox are not encrypted (they are encrypted but the key can be read out) until you set a master password. I don't think that this is a bug, but every virus could read those passwords nonetheless


TLS or IPsec protocol for client-server communication?

It depends on your use case which is not really clear from your question.

  What is the best protocol for client-server communication?

If you only care about securing data transfer between two applications (i.e. typical client and server scenario) SSL/TLS like used in the browsers is probably better because only changes on the applications are necessary.

IPSec on the other hand is more suitable for connecting networks with each other, i.e. VPN. In this case not only the traffic between two applications need to be secured but every traffic between two computers, independent of the application. This requires deeper changes on the systems which usually require administrative rights and thus is too complex if you just want two applications communicate securely with each other. You could also use SSL based VPN solutions instead of IPSec to create a VPN between various systems and it is more a question of usability and coexistence with other technologies (like traversing firewalls or NAT) if you choose IPSec or SSL VPN  if you need network level instead of application level secure connectivity. Both offer adequate security if properly set up.


Norton Symantec Flagging my python script as Trojan.Bayrob9

My question is, is it more likely that I have an unrelated virus on
  my own computer, or that my python program is being treated as a
  virus.

I think your python program is being treated as a virus.
Why?
See here

  This signature detects Trojan.Bayrob communicating and requesting
  information from its controlling server.

And you are trying to connect to a FTP server,Couple that with trying to write data on the disk as a malware dropper and the fact python gets flagged falsely by antiviruses left and right.


Monitor mode not sniffing from other devices on the same network

If your other devices (Pi) are sending lan traffic over a network switch / router, it’s likely the traffic is not visible as the switch or router isn’t sending (routing) traffic to all ports (not spanning traffic to all ports). If your switch supports it you can look at making configuration changes to make it behave like a hub type device where all traffic goes out all ports, but that could easily end up in a packet storm or DoS condition.


You put in the DMZ the servers which must be accessed from the outside. Since they are reachable from the external World (which is assumed hostile), these servers are potentially subject to hijack by attackers. The DMZ is a containment area so that a subverted server does not gain immediate access to your most valuable data (which will be presumably kept in the inner network).

Your AD and SQL servers are meant to be used only by machines from your network, not by machines from the outside, so you put them in the inner network. Your Web server is meant to be contacted by external clients, so put it in the DMZ. Similarly, the DNS server which publishes to the outer world your domain (e.g. the IP address of your Web server) is also meant to be accessed from the outside, hence DMZ.

There is no rule without exception. Occasionally, you will need to have some data path from outside to the inner network. Typically, emails come from the Internet but must ultimately appear on desktop systems. You normally want to store the incoming emails in servers which are in the inner network (this is the presumed safest place in your network) but if you run your own SMTP server (for incoming emails), then that one has to be in the DMZ.

It really depends on your exact situation, but the rule of thumb is simple: DMZ is for that which can be contacted from the outside.


How is password information stored and used on Android accounts?

Android uses AccountManager to store the passwords. By rooting a phone you can access the encrypted store. What happends now depends on the password you use to lock your phone (from which is derived the encryption key for the store).

As you can imagine, a 4 digits PIN is not going to resist long. A fingerprint (or other mechanism with large entropy) will not be cracked.


How do you overcome the problem of the salt being public and known by the attacker?

The problem here is that the salt mission isn't to be "secret", the purpose is to be unique so when an attacker "try a password" with that known salt it can only compare the generated pass with this one original hash because all other passwords will have different hashes.
For example:
Consider not having a salt:

user1:hashpass1
user2:hashpass2
user3:hashpass3
user4:hashpass1
user5:hashpass5

As you can see, user1 and user4 use the very same password because the hash generated are identical. So, when an attacker find this, he can hash one common word, for example: "rabbit" and then compare rabbit against the whole password hash database. He will also know that all the identical hashes has been generated with the very same password.
This is great for an attacker because he only need to hash ONE time to compare it hash against the whole database.
On the other hand, consider the very same salted user table

user1:salt1:salted1hashpass1
user2:salt2:salted1hashpass2
user3:salt3:salted1hashpass3
user4:salt4:salted4hashpass1
user5:salt5:salted1hashpass5

Now all the password hashes are different because of the salt, even user1 and user4 who used the very same password has different hashes.
This is bad news for an attacker he will need to compute the word rabbit with every single salt he finds in the database so he will a lot of time to do this. And this is the real value added by the salt.


Is there a common name for a software defect that leads to unexpected transfer of secret over the wire?

This bug is a buffer overflow -- the "reading" kind. A buffer overflow is where some code uses a buffer (a sequence of elements in memory) and accesses elements beyond the boundaries of the buffer (usually, it is called "overflow" when the access is past the last element, and "underflow" when it is before the first element).

Traditionally, the buffer overflows which lead to the biggest security holes are those where data is written past the buffer end, because it allows an attacker to alter the behavior of the attacked software, up to an including launching a shell. However, read accesses beyond the buffer end can be an important security issue, as your example shows: it can lead to leakage of confidential data (an encryption key is just the archetypal confidential data).

I have not encountered any specific term for the situation where the buffer overflows leaks confidential data which turns out to be an encryption key. Most pedagogical presentations of that issue use "credit card number" as a striking example of why data leaking is bad.


How to understand socat certificate check limitation?

If you only check that the certificate is valid in the PKI, but not that it matches the server name (either the domain or IP address), then you can be fooled by a certificate issued to a different site.

Suppose:

I own malicioussoftware.com
Thus I can but a certificate for malicioussoftware.com
You (attempt to) connect to https://www.microsoft.com, but I set a MiTM and answer with my malicioussoftware.com certificate.
Your socat sees the certificate is valid (it is signed by a trusted CA) and happily goes on.


Feasibility of time-based database brute-force attacks on websites

How feasible the attack is depends on how much noise you have to remove to get to the signal you want to have. If you can do a lot of tests against the website you should be able to increase the level of signal which might be enough to filter out enough noise to make this kind of attack feasible. But details depend a lot on the actual setup of the system you want to abuse.

To fight this kind of attack you use operations which are deliberately constructed so that their behavior does not depend on the input. Such algorithms are an important part of practical cryptography, not only for simple string comparison but also for hashing and encryption. And timing is not the only side channel but you have also need to look at power consumption and even weirder side channels like radiation.

And you probably not only need to have a look at timing attacks against string comparison. Your web application might leak other data which makes brute force easier, like behaving differently if the username exists or not.
Please also note that simply hashing before comparison might not help if the hash function you use is not resistant against timing attacks itself.

I think the best approach if to have some serious rate limiting for the number of login attempts. This not only makes brute force much harder but also will probably make timing attacks infeasible because their is too much noise around and the signal can not be amplified due to the rate limiting.


Exploiting SUID Binary that connects to SSH server

If may be vulnerable because it runs the ssh binary without specifying the full path. To test this:

Copy bash into a file called ssh in your home directory.
Set PATH to include your home directory at the beginning.
Try running connect. If it's vulnerable, you will get a root shell.


Does hashdump also dump domain creds when run on a domain controller

smart_hashdump will query a Domain Controller's lsass to dump hashes, but the regular hashdump will only get what is available in the SAM database for users (usually IT admins) that log into the domain-controller server directly (whether on-console, via RDP, or some other remote mechanism).

domain_hashdump uses the NTDS.dit file to extract all Domain Users, including historical ones. See -- https://www.rapid7.com/db/modules/post/windows/gather/credentials/domain_hashdump -- for more information


The term Zero Day or Zero Hour can apply to any type of attack. It's really just a classification given to the time period at which a vulnerability has just been discovered by a person or organization but has not yet been disclosed publically.

Some definitions also include the first day or "Day Zero" of a vulnerabilities announcement and the race between attackers and defenders to attack or defend their systems when this type of announcement is made.

Zero Day attacks are particularly dangerous because for the short time period they haven't been disclosed the attackers can effectively compromise some level of system access across almost all systems which are vulnerable. In some cases, this can give an attacker access to millions of devices or access to lots of sensitive data.

Once it has been disclosed publically or there is a known remediation it is no longer considered to be a Zero Day. Note: Some definitions vary here.

So there is no "solution" to preventing Zero-day attacks as new vulnerabilities and exploits will always be discovered before the remediations to prevent such problems from being exploited can be created.

Effectively the holes will always exist before their respective patches.

This said there are additional defenses which can be implemented to reduce the risk from certain types of Zero-Day attacks or limit their damage but it is not possible to anticipate all attack vectors.

This is really why you want to have multiple security tools because at any given time one layer of defense (one of your security tools can fail or be vulnerable).

In other words, if you think of security as a function of time at some point a vulnerability will exist even on the most well-secured networks.

If you only have one level of defense protecting your data your security will look like the following:

Time: ----->

Layer 1 Security: --------------------    ----------------
                 Zero Day occurs here ^   ^ vulnerability fixed here.

If you have multiple layers of defenses (or defense in depth) in theory as different vulnerabilities come out in time your defenses will look more like the following:

Layer 1 Security: --------------------    ----------------
Layer 2 Security: --------------    ----------------------
Layer 3 Security: ---   ---------------------    ---------

Even though each layer of security gets vulnerabilities from time to time they don't all align for an attacker to get through all three layers. In rare cases, this can happen but statistically multiple layers can provide much better security than one layer by itself.

One of the best defenses against Zero-Days is a very disciplined staff keeping multiple layers of security up-to-date. Discipline is key here, the layers just buy you more time.


When RSA keys are too small, the private key can be derived from the public key. This means the attacker doesn't even need to have access to a signature created by the private key, all he needs is the public key. It doesn't matter if the key is used for encryption, signatures, both, or nothing at all.

The current largest RSA key known to be broken is 768 bits, but governments and organizations with large amounts of computing power may be able to factor a 1024 bit key in the near future (perhaps even today), so 2048 bit keys are generally recommended now.


Protect files on webserver, allow only internal use

The files are public for the users' browsers to be able to play them, so you cannot prevent users downloading them for other reasons (or indeed just saving the copy in their browser cache).

If you want to stop people reusing them in-place from your website (which might be your main aim - someone else referring to the file on your site causes you server load and bandwidth use), you can add a check on the HTTP referrer field. See for instance http://www.htaccess-guide.com/deny-visitors-by-referrer/ .


Should 2FA over SMS be considered insecure in the wake of recent SS7 attacks?

The newest draft of the NIST Digital Identity Guidelines deprecates the usage of Two Factor Authentication via SMS.

I would recommend utilizing Google Authenticator (or similar technology) to facilitate 2FA moving forward, and abandon SMS based out of band verification.


Why would someone keep sending money to my Paypal account without my consent?

It would be wise to contact Paypal security immediately. This may just be a mistake but it could also be part of a scam to be able to "freeze" funds or access your account legally to recover transferred funds plus additional funds.

I would also recommend to immediately change your e-mail and Paypal password. Someone may be using your accounts to launder money and it's possible they may have more access to your on-line accounts than you think.


Fingerprinting Windows Architecture from a file on remote system

There are several hints, but the most obvious ones would be:

On the current Windows versions the existence of C:\Program Files (x86)\ tells it's a 64-bit system. Any 32-bit version doesn't have it.
You could download C:\Windows\System32\ntoskrnl.exe. On it's version X.Y.Z the X.Y reveals the Windows (NT) version and Z the build. (5.0 for 2000, 5.1 for XP, 5.2 for 2003/XP64, 6.0 for Vista, 6.1 for 7, 6.2 for 8, 6.3 for 8.1 and 10.0 for 10).
Such files as System32\license.rtf, system32\eula.txt or C:\Windows\inf\layout.inf might reveal the license version (Home, Pro etc.)


Should we force user to HTTPS on website?

Set up a rule which redirects any attempt to access the site via HTTP, over to the front page via HTTPS (redirect any attempt to access anything matching http://www.example.com/* to https:/www.example.com/).

Enable HSTS.  This tells browsers to connect to your site via HTTPS in the future.

Set the secure flag on all cookies.

Make sure pages delivered over HTTPS don't load any content via HTTP.

Read the following questions on this site:

Is a forced rewrite from http to https secure? What does SSLRequireSSL add?
HSTS extra security over HTTPS
Guidance for implementors of HTTPS-only sites (Server side)
Options when defending against SSLstrip?
Strict Transport Security — max_age value
What are the pros and cons of site wide SSL (https)?


Is it good or bad to use group in sudoers file instead of using aliases?

Using groups for sudoers entries allows you to manage filesystem permissions (which by default are user- and group-based) in the same place as sudo rules. Using User_Alias instead of groups means all aspects of sudo rules are in the same place but makes it more difficult to manage sudo rules in the same space as filesystem permissions. So it's basically a trade-off; neither method is objectively "good" or "bad".

On balance, because my current environment works this way, it seems easier to use groups to manage both sudo rules and filesystem permissions as part of a wider role-based authorization mechanism. Ideally these authorizations would be distributed via a system such as LDAP, and would manage the groups and the sudo rules on all your servers. The security properties of the system would be dictated by the authorization system as a whole, not just your sudoers files.


Following the ideas listed in comments above (thanks to Neil et al.) I found the Google Email transparency report:

http://www.google.com/transparencyreport/saferemail/?hl=en

This makes it very clear that Gmail>Gmail messaging is encrypted:

  Is email from Google users to other
  Google users encrypted in transit?

  Yes.  This includes Gmail, Google
  Apps and notifications from
  Google+.  That's why this report is
  focused on email deliveries where
  Google is only one of two providers
  involved.

So I think this solves the problem.

When receiving inbound email to a gmail account, one can check the DKIM signature to verify the email originated from a Google SMTP server (and thus was encrypted all the way to your gmail inbox)

In the outbound direction, you know your email originated from Google services, and thus will be encrypted all the way to the recipient's gmail inbox.

If someone can both send email and respond to a challenge sent via email (all within gmail), then I think this would be very compelling evidence of account ownership. Of course, a Google engineer could still inspect the messages at rest,  but I'm willing to accept such individuals as being in the class of "authorized to send/recv email from that email account."


Is it insecure to let users know which framework I am using?

Security through obscurity is not sufficient, but can be used aggregated to other security mechanisms and practices. Always remember that system security should not depend only on the secrecy of the implementation or its components.

You can know the framework code very well, but you can't suppose it's completely safe. Hiding it does not change that, but certainly can add an extra safety, which doesn't mean you shouldn't care about how code is implemented because it's hidden.

Avoid unused libraries, keep the code clean and lean, validate input data and encode output data, authenticate credentials, control access, treat log error messages, etc. There are a lot of good practices that should be used, because only hiding your code is not enough.


What are the strengths and weaknesses of using a single 'burner' computer vs. many public access computers over a sustained period?

Quick answer

Buy and configure a disposable computer.
Limit device usage to a single purpose.
Follow information hygiene practices.

  Disposable vs public access computers

Firstly, the reconstruction of your data and conduct by third parties depends on whether your conduct was localised or networked.

The reconstruction of network communication involves tracing a thread through various servers with search warrants until your identity and conduct is known. The reconstruction of localised behaviour requires either physical access to the computer or knowing your location whilst you are using it in order to eavesdrop in a variety of ways.

So:

A disposable computer is only marginally better than public computers for internet activity, as most of web anonymity depends on following strict rules of compartmentalisation and online hygiene.
A disposable computer is generally better than public computers for non-HTTP network communication as public computers usually lack appropriate tools like ssh, tor, freenet and pgp.
A disposable computer is quite superior for all localised activities as you control your data and can destroy it when required.

You pay for this improved anonymity by having to buy and configure the single-purpose disposable computer.

Public computing can cost nothing and requires minimal technical expertise to use within the limits of its anonymity. However availability of public computing is wildly variable, both in time of day and location - which limits how random your access behaviour will really be.

  Regarding disposable devices

Let us consider a disposable computer as any computer that you are willing and able to physically destroy to protect sensitive information or conduct.

A distinction should be made between self-contained disposable computers and live-boot distributions requiring a host computer to execute instructions. There are also new pc-on-a-stick hybrids that combine the portability of USB with the security of isolated CPU and storage.

Mobile phones are either a dreadful or an excellent option for anonymity - depending on what type of operating system and software is installed. Typically mobile phones are dreadful as they haemorrhage information out of every conceivable transceiver; know your location and conduct intimately; explicitly aggregate your identity for various commercial reasons; and have the interface security of a wet paper bag. However, a hardened custom OS with the transceivers tightly controlled or entirely disabled can make for an excellent option under ordinary use cases.

Laptops and netbooks are less portable and typically more expensive disposable solution than a mobile phone but require far less technical expertise to establish as anonymity-orientated machine.

Live-boot USB sticks will rely on the security of the host computer and hence the level of trust in that computer. They are the cheapest and most mature of the portable anonymity solutions, but you will find many public access computers disable booting from USB or prohibit such conduct in any case - as the flow of access is both ways. You could in effect manipulate the (unencrypted) host computer.

PC-on-a-stick solutions are a less mature technology than live-boot disk-images but, depending on their operating system and feature set, are probably the best overall solution for anonymity as they work with any accessible HDMI monitor and almost completely isolated from the surrounding environment.


Zenmap: Can't get hostnames for clients just IP addresses

Without knowing what command you have used for the scanning, it is not possible to tell you why they hostname didn't come up. While running a scan in Zenmap you can see the command it is executing.

Try running this command in Nmap or in Zenmap

nmap -sL 192.168.1.1/24

This command will give you the hostnames. The -sL flag tells nmap to do a simple DNS query for the specified range of ip. This allows you to find hostnames for all of the ip's without having sent a packet to the individual hosts themselves.

nmap -sn 192.168.1.1/24

You can use this command to scan every client in the range using the wildcard. This will give you the hostnames along with their IP addresses, and only pings the hosts to discover them.


This entirely depends on what you are doing with the username stored in the cookie.  If you are automatically trusting that the username that is provided by the cookie is valid, then you are effectively inviting impersonation of users by hackers.

If, on the other hand, you are simply storing the username so that they can automatically have the username filled in the next time they go to login, it is perfectly fine since a username is not secret information.

If, for some reason, you needed to use a cookie to store authentication, the preferred approach is to use a randomly generated session identifier that is tracked on the server and can be expired.

If server side storage is not available, the server can encrypt the username and an expiration date (and optionally an IP from which they connected) with a symmetric key (like AES) and then pass that encrypted value to the cookie.  The server can then verify the cookie later without an attacker being able to alter it.  The main drawback to this approach is that once a cookie is issued, it can't be invalidated if the user wants to log out all their sessions (because, say, their computer was stolen.)


list running applications that are linked against a compromised library

UPDATE: Here's a Bash script that I think does more of what you're asking for.  It will scan currently running processes and list RPM packages that contain libraries that are currently loaded in memory for those processes.

#!/bin/bash

procs=$(find /proc -maxdepth 1 -type d -name "[0-9]*" | sed 's@/proc/@@')

for proc in $procs[*]; do
  if [ ! -f /proc/$proc/cmdline ]; then
    continue
  fi

  cmd=$(cat /proc/$proc/cmdline | sed 's/[\s\n]+//g')

  if [ -z "$cmd" ]; then
    continue
  fi

  echo "**** Scanning pid ($proc): $cmd"
  echo

  echo "Dependent RPM Packages:"
  (
    libs=$(sudo lsof -p $proc -a -d mem 2>/dev/null | awk '{print $NF}' | grep "\.so")
    for lib in $libs; do
      echo $(rpm -qf $lib)
    done
  ) | sort -u
  echo
done

You could write a simple Bash script to figure out which binaries are reliant on a particular library.

To get the list of binaries on disk affected:

#!/bin/bash

dir=$1
lib=$2

for bin in $(find $dir -type f -executable); do
  ldd $bin | grep -q "$lib" && echo $bin
done

Or in the case of running processes on the system you could grep ps -ef instead and use ldd the same way as above.

Depending on your flavor of Linux you could also find how a particular package update affects your system based on the libraries contained within it.

On a CentOS system you could do the following to get the list of shared libraries in a package:

$ rpm -ql zlib | grep "\.so"
/usr/lib64/libz.so.1
/usr/lib64/libz.so.1.2.7

Then you could again use ldd on system binaries to determine which binaries use the listed libraries.


Chrome does not show green bar with EV SSL but firefox and IE does

BEAST attack Vulnerable INSECURE (more info)

  RC4 Yes PROBLEMATIC (more info)

These warnings are not directly related to your certificate.  They're more about your SSL configuration.  When a client connects to your server over SSL, the client and server will negotiate which protocols they want to use to exchange keys and encrypt data.

BEAST is a vulnerability with SSLv3 and TLSv1.  Basically there's a crypto flaw in SSLv3 and TLSv1 (fixed in TLSv1.1, which isn't widely implemented) that allows a hacker (man-in-the-middle) to attack long running sessions.  You can mitigate this issue by configuring your server to use ciphers that are immune to BEAST and to prefer those ciphers.

On nginx the configuration looks like this:

ssl_ciphers RC4:HIGH:!aNULL:!MD5:!ADH:!kEDH;

ssl_prefer_server_ciphers on;

This will use RC4 with clients that support it and fall back to AES.


Is hashing the hash considered an extra level of security

Assuming the hash is being cracked using brute force techniques, hashing the hash would mean that theoretically you will need more time and resources to crack that hash due to the fact that you need to execute multiple iterations of the algorithm.

However, having said that, if it is time you are looking for MD5 is most certainly not the way to go. In order to make a hash as difficult to crack as possible I'd recommend a "slow algorithm" like PBKDF2.

By doing multiple iterations of PBKDF2 you will make the process of cracking the hash so slow (relative to other algorithms) that it will become virtually impossible to crack the hash in any reasonable amount of time.

Edit: When I say multiple iterations I don't mean 2 or 10, I mean thousands or hundreds of thousands depending on the acceptable amount of time you are willing to wait for a legitimate hash to be generated or compared.


How does TLS work (RSA, Diffie-Hellman, PFS)?

Frankly I don't expect this to be terribly useful. Be that as it may ....

As a preliminary matter almost everything you say is for TLS up to version 1.2 only. TLS version 1.3, which makes fairly major changes in the protocol, was released last year (after a long delay) and is now in the process of spreading; based on historical experience it is likely that TLS<=1.2 will be pretty much gone in something like 3 years. To be fair, most of the resources you can easily find online, notably including the Ursine Epics at #20803, pre-date 1.3.

  In either case, the typical TLS Handshake looks like this:

Not either, what you describe covers only RSA; DH is different. More below.

  ... In addition, a random 28-byte value called ClientHello.random ....
  ... ServerHello message ... along with its own random 28-byte value called ServerHello.random and a digital certificate.

The fields named .random are actually 32 bytes, split into a 4-byte timestamp (which is not random if your computer's clock is even vaguely correct, as it should be) and 28-bytes of actual random data. The value used in key derivation etc. is the 32-byte value.

Strictly speaking the server certificate is not in the ServerHello message, it is in a separate message. However, both these messages, plus ServerKeyExchange when applicable and ServerHelloDone always, can be part of one record and are usually part of one TCP-level transmission. More substantively, if the server cert requires one or more intermediate or 'chain' cert(s) to be verified, which is almost always the case nowadays, that(those) chain cert(s) should be included as well; there are many Qs on several Stacks about "browsers consider my server connection secure but $other_sw gives $some_error" and this is often due to not correctly configuring a chain cert. (The A often varies depending on the server software involved.)

  The client verifies the server's digital certificate against its trusted CA store. Then the client creates a pre_master_secret, encrypts it with the server's public key extracted from the server's digital certificate, and sends that back to the server. This is known as the ClientKeyExchange
  The server decrypts [premaster] using its private key, and then generates a master secret

The client verifies the server cert, (usually) via its chain, against the client's truststore, AND verifies that the server cert matches the name (or possibly address) of the server the client wants to connect to. (If we want to connect to HonestBank.com, and trying to connect gets us a cert that was issued by a trusted CA to WeAreCrooks.com, we don't want to send our bank info on that connection.)

Both the server and the client derive master_secret from premaster and the 2 random's.

If the server requests client authentication, also called client certificate or 'two-way' or 'mutual' authentication, the client actually sends Certificate before ClientKeyExchange and CertVerify after. This is all explained in 5246, but is rarely used.

  Afterward, the client also sends ChangeCipherSpec record (6 bytes) to the server, indicating it wants to use symmetric encryption ....
  From this point onward, all traffic will be communicated over TLS and are encrypted.

After CCS all traffic is encrypted and authenticated; both are important. The methods vary: older ciphersuites use a (pure) cipher to encrypt and a (separate) HMAC to authenticate (HMAC = Hash-based Message Authentication Code); 1.2 also had new (in 2008) authenticated ciphers, officially called AEAD = Authenticated Encryption with Additional Data, which do both encryption and authentication in one combined operation; compare section 6.2.3.3 to the immediately preceding sections.

  Question 1: What is "master secret" in the derivation? In other words, what is the actual value?

It's different for every session, and nobody except the two endpoints (client and server) should know it, hence 'secret'. (Although sometimes debugging features let you extract it; there are several Qs on those.) Its value is computed using the formula you posted, from 8.1. In case the 'search' function on your browser is broken and some flaw in your display makes the table of contents invisible, PRF abbreviates Pseudo(R)andom Function and is explained in section 5.

  Question 2: How does client encrypt its message? What key/secret is used? I am not sure the role of master_secret?

The master_secret is used to derive multiple working keys, or more exactly secrets; see section 6.3. The client uses the 'client_write_key' to encrypt, and the server uses it to decrypt. For ciphersuites that use IVs, which in 1.2 is only some AEAD ones, they also use the the client_write_IV. For ciphersuites that use HMAC, which is the non-AEAD ones, the client uses client_write_MAC to generate the HMAC, and the server uses it to verify. See Are session keys just the symmetric keys? or cross https://crypto.stackexchange.com/questions/1139/what-is-the-purpose-of-four-different-secrets-shared-by-client-and-server-in-ssl .

  Question 3: In 3 (RFC section 7.3), it says the following, what are those "random values" and what are their purpose?
  - Generate a master secret from the premaster secret and exchanged random values.

This is exactly the formula you posted in your 3 from section 8.1. The ClientHello.random sent to the server, and ServerHello.random sent to the client, are exchanged random values, and are combined with the (shared) premaster_secret to generate the (also-shared) master secret.

  Question 4: I often read the term "session key". What is it? Is it the master_secret?

It can be either the master_secret, or the derived working keys/secrets (plural), or both. In particular, session resumption (aka re-use) in TLS<=1.2 is done by saving the session-id (in ServerHello) and the corresponding security parameters including the master-secret, and then using them on a subsequent or even concurrent connection.

  RSA

  I know that RSA can be used in step 3 above for integrity control, meaning using public-private key asymmetric encryption so pre_master_secret is not readable in plaintext.

'Plain' RSA keyexchange does use RSA encryption, which is a type of asymmetric encryption aka public-key encryption, so that pre_master_secret is not readable. Although asymmetric or public-key cryptography does use public and private keys, we don't normally say 'public-private key'. I have no clue what you mean by 'integrity control'; RSA encryption does not much resist an adversary manipulating the ciphertext, which allowed an attack by Bleichenbacher that remains an issue. The (only) protection on a plain-RSA handshake is the PRF values in the Finished messages, which functions as a kind of MAC (as long as at least one endpoint is honest and correct).

  DH The major weakness of using RSA is that using server private key. An attacker can record all traffic and decrypt traffic if the server's private key is compromised. So to provide forward secrecy 4, DH can be used.
  DH works on the principle of discrete algorithm. The mathematical properties allow both sides (the client and the server) to generate its own secret (a, b respectively), and derive to the same shared secret given p, G and g^X mod p (where x is a and b respectively) over the public channel (the world can read them) 5.

That's discrete logarithm. More exactly, Diffie-Hellman ephemeral provides forward secrecy; it is the 'ephemeral' that is critical. 1.2 (and earlier) also defines static (non-ephemeral) DH keyexchanges, but these are practically never used and serve mainly to cause confusion. (They are deleted entirely in 1.3.) There are technically two variants: the original DH-ephmeral using integers, designated DHE in TLS; and the elliptic-curve version, designated ECDHE. Although the same principles apply to both, the actual code (and data) to implement them is quite different.

  Question 4: I believe all subsequent traffic will be encrypted using the shared secret, correct

Not directly. The secret generated by [EC]DHE agreement is used as the premaster-secret, in the same fashion as above: first derived to the master secret, then to the working keys/secrets. Compare sections 8.1.1 and 8.1.2, immediately after the excerpt you posted.

  Perfect Forward Secrecy (PFS)
  To ensure no one can read prior logged traffic, PFS was introduced. Basically, instead of using a long-lived shared key, client and server generate short-lived session keys which are discarded from memory.
  Question 5: What are the short-lived keys? X (a, and b respectively) of client and server's?

Yes. Except that although generic DH is often described in terms of a/A and b/B (canonically, Alice and Bob), the TLS specs use different notation. For integer-DHE in 5246, the public keys for server and client respectively are dh_Ys and dh_Yc; (corrected!) the corresponding private keys presumably are Xs and Xc, but are not shown. For ECDHE in 4492, the server public key is simply named public while the client one is named ecdh_Yc (even though in ECC generally we use X,Y for coordinates of a point, and call the privatekey (integer) d and the publickey (point) Q) and again the private keys are not shown.

  PSF and RSA
  My understanding is RSA is used for authentication (what 'server' sends is coming from 'server', not MiTM). There's HMAC for integrity checks, which is generated during key exchange.
  Question 6: Is that right?

(That's PFS. Or just FS.) I'm not at all sure what you're saying, so to mostly repeat what I said before:

for RSA keyexchange, the premaster is encrypted by RSA with the server's publickey in its certificate, and the only integrity check on the handshake is Finished, which uses PRF, which is based on but different from HMAC
for [EC]DHE keyexchange, the keyexchange parameters are signed with the server's publickey in its certificate. That key and thus the signature may be RSA (in either case), or it may be DSA (also called DSS for historical reasons) or ECDSA depending on the keyexchange
regardless of the keyexchange, depending on the cipher either HMAC or AEAD (but not both) is used to authenticate the data traffic


You're focusing on a very narrow scope here. The CIA triad is about security of a whole system, not just an encrypted message.

That being said, all elements of the triad do apply to your example:

Confidentiality: As you mentioned, encryption's primary purpose is to enforce confidentiality.
Integrity: Encryption does not automatically provide integrity. An attacker could swap an encrypted message for a previously seen encrypted message. An attacker could abuse ciphertext malleability in order to modify the plaintext without knowing the key, e.g. if a stream cipher was used without an authenticity record on the ciphertext.
Availability: An attacker might delete or corrupt the encrypted message, or leverage a denial-of-service (DoS) attack against the system that contains the encrypted message.


Can change management for PCI compliance be accomplished via simple emails?

We used email for change management for a while, and as long as we had a record of it, our auditor was satisfied. However, email is seriously lacking in features and not well-suited to the task.  It's difficult to track, and hanging onto a string of emails and then providing them at audit time is a nightmare.

However, it's easier with other forms of software designed for tracking tickets. You can find decent, free CRM or helpdesk ticket software that can be used to track change tickets just as easily as a full blown ITIL package, but with less features.  The critical components are that you can track what is changing, who authorized the change, and the steps taken. This can be achieved through ticketing software that has the following features:

Allows you to record basic incident/call details
Allows you to assign tickets to people or groups
Allows you to enter notes
Allows easy reporting, or at least access to the database so you can write your own reports.
Bonus if it allows you to attach files and does so in a secure way.  This allows you to attach code review documents, threat models, or other artifacts associated with the change.
Bonus if it has workflow modules to to allow for approval processes (although those can be defined and just done manually)

The more detailed and specific the tracking/logs, the better.


Requirements for a smartphone anti-theft App

There are documented cases where the theft recovery tools were used against a legitimate user, so your concern is justified.  In general, if I was designing such a system, I would want the password to take control of the phone to only be known by the user and not stored on the service provider's system.

I would also want the password to be used to generate time based and one time use codes to send via SMS so that the phone would never respond to a replay and would not send the password clear.  Since a phone has a reliable time source (the cellular network), it should be possible for the phone to keep a good time sync with the server for this purpose.

It would still be potentially possible for the device to be hijacked, but it would require then require the user to allow their device password to be compromised.