How is Truecrypt any safer than just password-protection?

Yes, the password is what regulates access to your files. So it's the single "point of failure" but its also what keeps you safe.

  Suppose my computer is stolen and the thief finds the container and is savy enough to recognize it as a Truectypt-container. All the encryption will do me no good, right? Because the only thing the thief has to do is crack my password, open up Truecrypt and mount the container.

That case is exactly what encryption is for. If you use a strong password and a decent encryption algorithm, it may take an attacker forever to decrypt your files. Security is never 100% but the measure of security is determined by how hard it is for an attacker to get what he wants. The better your password and your algorithms, the higher your security (given that there are no software flaws and that you keep your password also secure)

Think about it: not only an attacker might be interested in decrypting your files but also you might be interested in keeping access to them. So there must be a way to identify you which usually is

something you know (a password)
something you have (a key card)
something you are (iris scan, fingerprint, voice recognition, etc.)

You can combine those methods to make access to your data more secure, but in general, that what grants you access can also be misused by an attacker. You cannot avoid that but only try to keep your passwords and smartcards for yourself.

Besides, there are more possibilities to attack an encryption scheme, e.g. if you have a backdoor in your encryption software or if you are choosing a weak encryption algorithm. You can only try to avoid that as good as possible by staying informed on these topics. Especially Truecrypt has had quite some problems with these ("WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues." See: http://truecrypt.sourceforge.net/).

What you may be after - since you talk about that the attacker recognizes the file as Truecrypt containers - is to hide the encrypted data. This is more about steganography than cryptography. You can put your data on a hidden partition on your hard disk or split it between more innocent looking files (incorporate it in JPEGs or whatever). But usually, hiding data is not as effective as encrypting it. If you are really paranoid you can, of course, do both.


How to authenticate an Add-In on interprocess communication?

Your very design - treating non-sandboxed processes running with the same privileges and owner as yours as untrusted - is incompatible with the Windows security model.
There exist ways to authenticate an application to another via IPC, and even to verify the binary that an application is running from and the signature on that binary. However, there is no way to prevent the following cases which would break your security objective:

a DLL loaded into the add-in / client process has created a hostile thread that can read the process memory, turning the client untrusted.
another process has used debug APIs to modify the client process in memory, turning the client malicious.
another process uses debug APIs to read the secret out of the client process after its retrieval (processes have ACLs which could prevent this, but any process with the same owner can overwrite that ACL).

Note that some of these could be prevented by doing things like checking the loaded DLLs or ACLs of the client process, or checking for open HANDLEs to the client process in other processes. However, these all fall victim to "Time Of Check to Time Of Use" (TOCTOU) attacks, where the attacker can ensure that the check passes (the client looks clean and trustworthy) and then invalidate the check result (inject DLLs, change ACLs, etc.) prior to the use of that check result (the service actually returning the secret).
Additionally, it is of course possible for any privileged (admin / SYSTEM / has SeDebug privilege) process to read the secret right out of your service's address space, without bothering with cooperative IPC mechanisms. Consider that MMC is frequently run as Administrator, implying that the user running it at least has the ability to launch privileged processes.
Leaving aside the privileged process case, though, you can avoid exposing the secret itself (assuming it's stored somewhere that other non-privileged users can't read) by instead having the IPC channel function as a relay for the information. That is, instead of the IPC client saying "Hey service, what's the secret?" and then directly using the secret to get the sensitive data, the IPC client could say "Hey service, what's sensitive data ?" and get the data without ever learning the secret.
Of course, this doesn't prevent that data from being exposed to other processes. Nor does it prevent other processes from taking over the legitimate IPC client and making it request all the sensitive data for them. At the end of the day, if you don't trust the programs that the user is running with the same privileges that they are using to run your process, you are trying to do the impossible. In that scenario - where the user themselves is potentially hostile (since they are presumably choosing to run, or at least enabling the running of, processes that want to steal your secret), there is no way in "full" Windows to prevent the user (or one of their "agents" i.e. processes they run with their full privileges) from learning a secret in one of their own processes.
Now, in fairness, you can make it hard to pull off such attacks. That's what DRM (in the form of media or software license checks) tries to do: it can't put a security boundary between the process and the secret (such as a license key, encrypted media key, or similar), so DRM authors put up what one security researcher described as a "nonsense boundary" instead. If the target process' address space makes no sense, and the process itself is constantly checking its own integrity and the binary is so obfuscated that it's hard to reverse engineer and remove all those checks quickly enough, then it can be quite hard to extract secrets from it. Still possible with time - anybody familiar with the history of DRM will note that most DRM schemes of interest to anybody (and some that were pure curiosities) have been cracked, sometimes very quickly - but maybe getting at least a short time is sufficient?

A few good questions, at this point, are:

What assets are you trying to protect, and how valuable is each one?
Where are the assets stored, and what are the trust boundaries around them?
Who are the attackers, that would want to access the assets? (If the user or any system admin is a potential attacker, you're squarely stuck on the DRM problem).
What are the attackers' privileges (if they're low, such as sandboxed Windows Store apps, then that's not a problem; if they're the same as your own - as seems to be the case - you have a problem)?
What are the practical attack vectors by which the attackers could try to access the assets? Answering this question requires thinking about everything each attacker can do - for example, things like the ReadProcessMemory API or potentially reading secrets right out of the file system or registry if they have enough privileges to satisfy, overwrite, or bypass the ACL - and is the part that is often trickiest for a novice to enumerate, but if you provide the info others can help you (as we've tried to do here).
For each attack vector, how severe is the actual threat (likelihood of successful attack multiplied by damage)?
How severe does a threat need to be before it becomes important to avoid it? In other words, how much risk can you accept?
For each threat that poses too much risk, is there any way to mitigate it?

This process - enumerating the assets, their protections, their attackers, the potential attacks against them, the threat due to each potential attack, and mitigations (if any) for those threats - is called threat modeling, and is very useful.


Does it make sense to choose a longer password than the output of a hash?

If you consider a set of potential passwords of size P, with a hash function with N possible output values, then the probability that there exists at least one collision in this set is quite low when P is less than the square root of N, and quite high beyond. See the birthday problem. As the Wikipedia page says, that probability is approximately equal to 1-e-P2/2·N.

With figures: if you use passwords consisting of 10 characters (uppercase letters, lowercase letters and digits), then P = 6210 = 839299365868340224; with a 128-bit hash function, N = 2128. The formula above means that there may exist at least one colliding pair among all these passwords with probability close to 0.1%. On the other hand, if you add one character to your passwords (i.e. the potential passwords have length 11, not 10), then the probability that there exists at least one collision rises to 98.1%.

Now all of this is about the probability of existence of a collision; not probability of hitting a collision.

Collisions are not relevant to password hashing. Password hashing works on preimage resistance: given the hash, how hard or easy it is to guess a corresponding password. Note that I said "a", not "the": for the attacker, it does not matter whether he finds the same password as the user did choose; he just wants a password which grants access, and any password which matches the hash output will do the trick.

Note that while MD5 is "broken" for collisions, it is not so for preimages (well, for preimages it is "slightly dented", but not significantly for the purposes of this question).

There are two ways to break preimage resistance:

Guess the password. This means trying all potential passwords until a/the right one is found. If there are P possible passwords with uniform probability, then this has cost at most P/2 because the user did choose one of the passwords, and the attacker will need, on average, to try half of them before hitting that exact password.
Get lucky. Try passwords (random, consecutive... it does not matter) until a matching hash value is found. This has average cost N/2.

The password hashing strength will be no more than the lower of the two. In that sense, using a set of possible passwords which is larger than the output of the hash function (e.g. P > 2128 for a 128-bit hash function) does not bring additional security, because beyond that point, the "get lucky" attack becomes a better bargain for the attacker than the "guess the password" attack, and the "get lucky" attack does not depend on how the user actually chooses his password. Please note that I say "size of the set of passwords" and NOT "password length". All the analysis above is based on how many password values could have been chosen, with uniform probability. If you use only 200-letter passwords, but you may only choose ten thousands of them (e.g. because each "password" is a sentence from your favourite book, and the attacker knows that book), then the size of the set of potential passwords is 10000, not 62200.

In practice, P is bounded by the user's brain (the user has to remember the password) and is invariably lower than N. A "very strong" password is a password from a selection process which uses a P of 280 or more; that's sufficient for security, and yet far below the 2128 of MD5 or the 2192 of bcrypt. But it seems unrealistic to expect average users to choose very strong passwords on average. Instead, we must cope with weak passwords, with P around 230 or so (meaning: try one billion possible passwords, and you'll have broken the passwords of half your users). Mitigation measures are then slow hashing (make each guess expensive) and salts (don't allow the attacker to parallel-attack several passwords at reduced cost). See this answer.


What's the relation between a Security Framework & Standards, Guidelines, Procedures and Policies?

I will reiterate my comment above so that this question has an answer. It appears to me that the confusion arises from how broad the term "framework" is. I believe the exact term you are after is "policy framework".

  A policy framework is document that sets out a set of procedures or goals, which might be used in negotiation or decision-making to guide a more detailed set of policies, or to guide ongoing maintenance of an organization's policies. A framework might be used by a large organization such as a company, educational institution, or government, to inform employees about whose approval is needed to make new policies, what rules new policies must follow, how policies should be communicated and enforced, and what high-level or long-term goals that new policies should try to support.


How to remove or at least change password from browser memory dump file

Your goal is effectively to control browser behaviour and prevent it from storing the password which was entered and sent by the user anywhere (neither cache nor password-storage). As this is client-side software, you generally can't. But we can work out a solution which will achieve what you want in most cases. Please do note that you will never have full control over what the browser stores in RAM, but this is not really a problem. An attacker capable of compromising RAM is also capable of logging keystrokes.

Prevent a submit event from happening

Most browsers notice when you submit a form, because you click a special button (type="submit"). This will probably promt the user "Do you want to store the password for this site?". To prevent this, you can implement this on your own. Don't set type="submit" but create a button <button onclick="performLogin()" that, if clicked, grabs the values of your input fields and wraps them in an HTTP-POST request to your site. If the login is successful, return the session key and write it to a cookie or whatever suits your requirements. Using this approach, you never trigger a real "submit event", but only a click event which won't promt the user for saving the password.

The cache question is trickier and I'm afraid, I don't see a consistent, reliable solution for this one as a browser won't let a random website dictate how it organizes its RAM. However, I can't see a huge drawback when ignoring it. As mentioned above, malicious code capable of reading arbitrary RAM are probably (not always) able to log keystrokes, compromising the password, which is what you are trying to avoid.

P.S.: Always be careful when implementing security measures or authentication mechanis on your own. As goteguru correctly said, "implementing your own security solution may have pitfalls". I'd increase this to "absolutely has pitfalls capable of screwing you over in various ways you never expected, if not handled properly".


How resistant are barcodes and QR-codes against attempts to change stored data?

... how secure is a QR-code?

Data in a QR code are kind of protected against accidental damage by having some error correction but they are not protected against deliberate manipulation. Also, an attacker might completely replace the QR code in the document with a different one.


Known strings to have the same MD5 hash, not colliding in real life?

... in which it clearly states that these two strings ...

No. It clearly states "...  two different sequences of 128 bytes ...".
There is a huge difference in these statements. In the first the strings are taken as they are. In the second one will hopefully realize that these are 256 character long strings which consist of hexadecimal characters and that one needs to convert these to binary to get the 128 bytes.
Once this conversion is done and the MD5 is computed from the actual 128 bytes one will see that both byte sequences result in the same MD5, namely 79054025255fb1a26e4bc422aef54eb4 (matching the article).
This can for example be reproduced by using this site and choosing bytes in format hexadecimal as input.


BREACH attack vs filtered reflected user input

If the user input is reflected verbatim with each request, your method probably does not protect against BREACH.

The most certain way to defend django is to turn off Gzip compression.

Alternately, you can XOR the token with a different pseudo-random value for each request.


The procedure when you are pentesting looking for open ports is always the same:

1º Run a port scanner

2º Check ports and services running

3º Find (or write your own) exploits for known vulnerabilities.

4º Report

In this case of RPC, as far as I know it isn't a big deal now. In the 90's it was very popular, but right now I haven't seen any vulnerability related with it.


Insufficient serial number entropy in GoDaddy certificate

It's perfectly valid for a serial number to be shorter than 64 bits; this can happen because the certificates use a variable length encoding (DER). The issue in this incident is whether the serial numbers contain at least 64 bits of entropy, i.e. whether they were generated from at least 64 bits of randomness. This can legitimately result in numbers where the highest bits are zero. For some certificates however, GoDaddy (and others) apparently used a method that caused the highest bit to be predicatable, thus effectively destroying one bit of entropy.

The CSV you linked is called "Final Serial Number List" in the bug report, which indicates that you're unaffected if your certificate is not included. However, the discussion about this group of incidents is still ongoing, and as far as I understand, there is still disagreement about the correct interpretation of the relevant standard (the Baseline Requirements). You can follow the debate here: https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/F8AS4MNVCAAJ


Webgoat missing function level access control lesson

Well its kind of a hard challenge.

First when you click on the human symbol to logout you should notice there is a role: User.

Also when you visit /users you should notice in the source code a hidden button like "admin" or something like that. So you need to try somehow change the role.

Logout and try to register again. Notice the post parameters.

So do the same on /users but with:

parameters in a list --

  {"parameter1":"value", etc }

add a new parameter role

  ( value: Admin wont work so try WebGoat_Admin)

and also change

  content-type:application/json


Firstly, often encryption is terminated at the perimeter by infrastructure which is dedicated to offloading SSL decryption. It makes it much easier to manage when you only have maintain a high degree of key security for a small (proportionally) group of servers which are dedicated to the role. The rest of your regular application servers can operate like normal without worrying about handling these keys.

Secondly, their keys would almost certainly be stored via a Hardware Security Module (HSM). These are dedicated hardware devices with a processor designed for maintaining security and being efficient at performing cryptography.

Finally, Google has its own intermediate CA certificate which it can use to sign its own leaf certificates. This allows them to use certificates with a far shorter expiry than normal, which somewhat reduces the risk of a key being compromised. The actual CA key can be kept locked away in an air gapped bunker and only accessed when it needs to sign a short term leaf certificate.

Remembering also that a CA doesn't need the leaf private key to sign a certificate, they could generate a private key which never leaves a HSM onsite at a remote data centre, then send the public key/CSR to the CA to be signed. They might even generate a unique private key for every single HSM device, that way a key never has to leave the device which generated it.

For example here's a print screen of a current Google certificate:

You'll notice that the certificate is only valid for 3 months, which is significantly shorter than most.

Edit: Google actually describes their policies in detail here.

  In the Google PKI, a Subscriber is an individual or an organization
  capable of using, and authorized to use, the Private Key that
  corresponds to the Public Key listed in a Certificate

...

  The Google Internet Authority servers are located inside of a locked
  cabinet or cage area in a locked server room. Access to the server
  room is controlled by badge readers. The private keys for the Google
  Internet Authority are stored in hardware security modules that are
  FIPS 140-2 Level 2 that are physically tamper-evident and
  tamper-resistant.

...

  Subscriber Key Pairs are generated (i) by the Subscriber by software
  supplied by their device/operating system, or (ii) by an authorized
  member of Google’s Information Security Team.

...

  Subscribers provide their public key to Google for certification
  through a PKCS#10 Certificate Signing Request. The preferred transfer
  method for sending this information is HTTP over Secure Sockets Layer
  (SSL).

Basically that's exactly how a regular CA works, except it's all conducted internally within Google.


You are trying to take something which is inherently online (sending and verifying an SMS OTP code) and make it offline. This is possible, but it will require great thought to do it correctly, and the approach you take will depend on your requirements (ie your question does not contain enough details to decide which is the best solution).
I think the first step is for you to examine security properties that a traditional online OTP system provides, and decide which are important for you to preserve in your offline system. Once you have this list of requirements laid out, the set of viable solutions will likely become obvious.

I am not intending to provide a complete list of security properties that OTP gives -- I leave that as an exercise for the reader -- but here are some ideas to get you started:

Uniqueness: Each SMS OTP code is unique and the client must provide the one sent to them (ie if the system currently has 1,000 active OTPs, then your offline system needs to only accept the one sent to this client and reject the other 999).
Lifetime / expiry: SMS OTP codes typically expire after 15 minutes. You will likely want your offline system to reject codes older than 15 mins (or whatever time period is appropriate for your offline use-case).
One-time use: As the name implies, OTPs are intended to be one-time use, ie you can only use them once. If this is a required property of your offline system, then you will have a significant engineering problem ahead of you.

Solution for "one-time" problem.
I don't know exactly your design requirements, but a solution that might satisfy the "one-time" property might look something like this:

Before leaving WiFi, the delivery driver indicates which customer they are delivering for and the time they expect to make the delivery,
The OTP server generates an OTP for that customer and gives the OTP code to the driver's app.
15 minutes / 30 minutes / 1 hour / whatever before the expected delivery time, the system sends that code to the customer via SMS. (you will likely need to make the lifetime of this code long enough to account for variance in delivery times, for example maybe 24 hours is not unreasonable here). At this point the server no longer needs to know the OTP code and could delete it from the server's DB.
When the driver enters / scans the customer's code, their local offline app records that code as USED and will not accept it again.
Since the OTP server generated this OTP for offline use, the server will not accept it directly, and it will not give that OTP code to any other driver's app (it will generate a new OTP if a new driver takes over that delivery). This way that OTP code will only work against the intended driver's app, and only once.


functioning ( behavioural based ) of an antivirus

There are common ways malware works - currently quite a few are using powershell for example to call out download the payload and execute. This is normally trigger from say Word.exe calling cmd.exe has then called powershell.exe with arguments.

So detecting if a process for cmd.exe has been created by word is an indicator of potential malware activity and has a child process of powershell.exe.

Now there are quite a few common attacks that have indicators such as these listed by mitre:
https://attack.mitre.org/wiki/ATT%26CK_Matrix

Given known attack types you can detect this behaviour and respond. If you start grouping the different types of chained attacks you would expect you can determine if to a certain degree if something is malacious.
A good example of a tool that monitors for malicious behaviour is sysmon

Sysmon can be configured to only look for certain types of behavior and writes to the windows event log.

Obviously if a new attack category with new indicators this becomes a problem.
So now you also begin to determine what is normal behaviour on a system using some ai techniques so if something out of the normal occurs it can be flagged and other indicators looked at.


What's a secure way to generate a keypair from a secret password?

You can achieve the same effect by encrypting the keypair with a key derived from your memorized password. So rather than 'generating' a keypair you'll be encrypting a pre-generated one.
Take your long password, and pass it through a key derivation function (e.g. PBKDF2), use the output to encrypt the private key, and then store only the encrypted file.
Hence in order for someone to compromise the pair, they'd need both your password and the encrypted private key file.


Security Risk of Stolen Session ID vs Authentication Token

I'm the author of the blog post you referenced, as well as the answer to the SO question you linked. Here are the answers you are looking for.

  A session ID is an opaque reference to actual session data stored on
  the server. It is safe insofar as it is random enough to not be
  guessed easily, and the data is safe because it is not directly
  accessible by or beholden to the front-end. The session ID is stored
  in a cookie to simplify authenticated requests.

Kinda. When a session ID is stored in an httpOnly cookie, the cookie itself is cryptographically signed (and can also be encrypted). JavaScript code can never access an httpOnly cookie (the httpOnly flag makes it impossible for JS code to view the cookie).

  An authentication token is a plaintext segment of JSON user data with
  a cryptographic signature that verifies the data's integrity. It is
  tamper-proof because of the signature, so no one can simply come up
  with their own token. The data it grants access to is safe on the
  server, except of course what is present in the token (which even then
  can be encrypted if need be). The token is also often stored in a
  cookie to simplify authenticated requests.

Kinda correct, again. Most tokens are stored in HTML5 LocalStorage (in JavaScript) because they are simply too large to fit inside of an httpOnly cookie. Cookies have a maximum data storage size of 4kb. If your token is larger than 4kb (which most are, since people use them to carry user information), then you must store them elsewhere. And the simplest way to store them outside of cookies is... you guessed it, LocalStorage!

Unfortunately, this has serious side effects.

  So here is what I do not understand. The way I see it currently, it
  seems just as likely that a token be stolen as a session ID, e.g.
  anyone breaking past my SSL and viewing my token would be able to view
  a session ID as well. Either event gives the attacker complete access
  to my account and all associated authorization. So in terms of the
  event likelihood and the resulting damage, is an authentication token
  really any worse than a session ID, as the article claims?

The likelihood of someone stealing a token from LocalStorage is far higher than that of a secure httpOnly cookie being stolen. And it's also substantially easier for a stolen token to cause mayhem because:

A stolen token can be used by an attacker to impersonate the user from anywhere (the attacker's network, proxies, etc.)
If an attacker is able to inject JS code onto your website, this won't allow them to access cookies, however, so that means the attacker would only be able to run JS code to 'impersonate' a user while the user is still on the website. Because once the user closes the tab in their browser, the JS code the attacker was running will no longer run.

There are vastly different abuse scenarios here.

  The one thing I could see potentially being worse for tokens is if the
  signing secret were somehow found out, in which case the attacker can
  do anything with anyone's account, rather than just mine. However I
  almost want to relegate this to the reasonable unlikelihood of someone
  first breaking RSA, in which case they can get past SSL, and then what
  good is a session ID anyway?

You're right that if an attacker can figure out the signing key, then they can tamper with an existing token (or create their own fake ones). But, this is highly unlikely because signing keys must be kept server-side. If you accidentally leak your signing key, for example, that's essentially the same thing as sharing your sever password with someone: obviously you're going to have a bad time.

The main difference here is in how the abuse can unfold. The article I linked to above is another post I wrote which details this in much more explicit ways. Hope this helps!


Does a lack of verified signatures for Windows Defender indicate malware?

No, it is normal for legitimate applications to appear as "not verified" in autoruns.exe. In my experience, this is normal behaviour and I have seen other legit applications that didn't appear as digitally signed. I wouldn't worry too much about what autoruns tells me if I were you.

This is why malware analysis makes use of various tools, either for static or dynamic analysis. There needs to be a much more detailed "inspection" of the characteristics and behaviour of the application to reach a verdict.

Here is a screenshot from my machine, to put your mind at ease:

What you CAN do, is to create some sort of 'saved state', to compare your system with at a later time, and possibly detect how a malware gains persistence. Remember, if you eliminate a malware's persistence, then you've 'theoretically' eliminated the malware:

Run autoruns.exe on a "clean" system and let it finish. (If you suspect your system is already infected with malware, then this process won't help you).
Click on File -> Save, and then save the .arn file.
When at some point you suspect that you have been infected by some malware, then run autoruns.exe again and when it finishes, go to File -> Compare and load the .arn file from step 2. If you notice some dodgy Registry entry that you can be certain it is not legitimate, then you can safely delete it.

However, this doesn't mean that you'll always be able to see the auto-start registry entry (e.g. see persistence through RunOnceKey, rootkit driver infection, etc). Nevertheless, it might help sometimes.


Can my employer monitor my web usage on my home network?

I'd assume your browser history gets synced because you're using Safari with iCloud syncing, or something like that.

If you're worried about that, you should be able to turn of Safari's syncing feature on both phones. Or maybe (I haven't used Safari in ages, so I don't know if it exists on Safari, but I assume so) use private browsing mode; I'd assume nothing you do in private browsing mode would leave your phone.

Finally, you could use two different Apple IDs, one for your work phone and one for your private phone. Seems like that would be the smartest thing.

Still, even if you continue syncing your browser activities, your employer shouldn't have access to it unless they have access to the account the apple id belongs to. If you're using your own private apple id, and not a company-provided one, and you did a factory-reset on your work phone before returning it, I'd assume the danger was minimal.


Virtual machines vs separate physical machines for testing potential malware

If you think that the executable is potentially unsafe, It is always better to access it in a network isolated PC. Considering threats like the recent zero-day vulnerability in VirtualBox (read more). We can never be sure of what's out there already. You can run it inside a VM inside the isolated PC with proper firewall rules configured as a safety precaution and always use up-to-date software.


Can you, with 100% certainty, guarantee the source location of a cyber attack?

Can these experts make these claims with 100% certainty? Why or why not?

You can almost never prove anything 100%, but for all intents and purposes you can be quite certain. Can we know for sure the Shadow Brokers leak was legit? No, but we can conclude any other option would be highly impractical.

But the American government is not providing that level of proof for the situation you mention. I have yet to see a shred of technical evidence of this particular statement.

Say, the american government suspects someone of hacking a presidential candidate. They could probably easily compromise their node with tools from the intelligence community. This would provide proof, and it would make all the bellicose rhetoric sound a lot less insane.

As far as i can tell, the most solid reasoning in this case is:

  “We believe, based on the scope and sensitivity of these efforts, that only Russia’s senior-most officials could have authorized these activities,”
  -James Clapper


This presumably is in response to https://www.kb.cert.org/vuls/id/475445.

The XML signatures will be different as the XML comments are part of the canonicalized XML that's signed.

Of course, the NameID value is test@user.com for the 1st and 4th examples, test user.com for the 2nd example and and test for the 3rd example.

The issue doesn't lie with the canonicalization method but rather with some SAML libraries which used the first text node as the NameID value rather than the concatenation of all the text nodes. For example, test@user.com could be changed to test<!--comment-->@user.com without affecting the signature and some SAML libraries would return test as the NameID.

Using http://www.w3.org/2001/10/xml-exc-c14n#WithComments would circumvent this issue but it would be still worthwhile checking whether your SAML library correctly handles embedded comments.


Python desktop application: storing cloud database passwords

If it is important to you that your users not be able to obtain the credentials needed to access the cloud services directly, your ONLY option is the indirect access (through a server) that you mentioned.
However, there may be other options, depending on the security model of your application. For example, if each user gets their own storage (not shared between users), you could create some lightweight users (possibly via Azure Active Directory? I'm not an Azure guru. For AWS you'd just use IAM accounts) that can access the cloud services directly, and then lock down (on the cloud platforms) what those users can do (e.g. in the DB, limit the user permissions so they can only run specified stored procedures rather than having free-form access to the DB). This might also work if storage is shared but with some restrictions (like read-only access to others' data). Things like S3 tend to be very free-form, though; if you give somebody an S3 access key, you can't really control what they put in there and you can only control what they take out by limiting the buckets they can access.


Specifying RSA OAEP label via OpenSSL command line

Based on the source it does not appear that such an option exists for rsautl. After some digging however, I discovered that pkeyutl supports the rsa_oaep_label option as a hex string:

openssl pkeyutl -encrypt -inkey path_to_key.pem -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_label:[hex string]


Should I sign software release keys with my own key?

The idea is the same as a public key infrastructure. The Root certificate authority (self-signed) signs the signing key. Root CA --> signing key

In the event the signing key is compromised, it can be revoked by the root CA, another signing key can be issued which is signed with the root CA. Then you can ensure the new signing key is issued by the vendor. It creates a chain of trust as we use with HTTPS. I am not saying a PKI does not have disadvantages, direct compromise (root CA) being one, but it allows for automation, easier validation and does not directly expose the self-signed certificate.

Notice the Root CA is offline, which should greatly mitigate the risk of compromise.

  is: is this a good idea to sign a release key (after having cross-checked multiple sources)?

This is quite a delicate answer. As the signing (release) key needs to be validated, otherwise, we could be downloading potential malware, and believe it was released by the vendor as the package is signed. My opinion is, the more sources we can validate from before using the signing key for long-term use, the better.

What happens if my signing subkeys are compromised? should give some insight.


Are these SQL injection checks a bad idea?

Doing this sort of blacklisting of words in your arguments is unnecessary with properly implemented stored procedures, and will only lead to bad user experience in the event that this misfires on benign content.

If you are using a stored procedure and structuring your query with the parameters that are passed into the stored procedure, you do not need to do these checks.

If, however, you are concatenating strings together and passing them into an EXEC call, you are opening yourself up to sql injection.  My advice is to simply use stored procedures for what they are meant to do, and rely on that for protection.

(As an aside - 25 characters for full name and email address seems a little too short to me.)


By implementing, I am assuming you mean one of the following:

1) Developing a vulnerable application yourself and then deploying it to one of your servers.

2) Taking an existing piece of software (likely an older release) that is vulnerable to certain attack. Perferrably, for learning purposes, the deployed software will already have common vulnerabilities that have been publicly disclosed on the Internet.

Here are some examples of common vulnerabilities you may find in real-world software deployments that may be within your scope:

Denial of service vulnerabilities via a buffer overflow in a C/C++ applications.
Directory traversal vulnerabilities in misconfigured web servers.
Code injection vulnerabilities in web applications.
Integer overflow vulnerabilities in C/C++ applications.
Information disclosure vulnerabilities in any sort of application.
The list goes on...

Whether you want to develop your own software or use something that already exists is up to you.

Overall though, I feel like this is a very broad topic, but I think one of the best ways for learning more about software vulnerabilities is by reading existing bug bounty reports and technical details found in CVEs.


More specifically, how do I protect the data that is sent to and from the remote server?

I'm not sure if I properly understood your question. But I understand the above part that you just want to protect the data in transit between client and server. In this case HTTPS (or plain TLS) is enough. This will automatically use different encryption keys for different TLS sessions (where TLS session will have the same lifetime as the TCP connection unless session resume is used)  so the risk you imagine of having the same encryption key on all devices does not exist.

But HTTPS or TLS will not protect against somebody who has physical access to the device and intercepts the data there before encryption and after decryption. It only protects the data in transit.


Cuckoo is an automated sandbox meant for malware analysis. It skips the first N seconds of delay functions when a program starts.

NtDelayExecutiom is commonly used to prevent dynamic malware analysis, so it's skipped at program start to prevent the analysis from taking a prohibitively long time.

The function call output is letting you know it skipped a 1000 millisecond delay (1000ms = 1 second).


Considerations for security release notes

Great question! I've written a few of these, but always had a very formal way of doing it, such that I never had the option to think about what's really needed...

Coming from the perspective of the people who have to use and support and upgrade your product, I think you need to cover:

High level information (and a pointer if possible to details) - on why the fix was needed.  Something like - "corrected string buffer handling in XYZ component" is helpful.
Known issues - anything that you couldn't fix yet that is still in there.
Upgrades of third party software and a place to find current baseline of all 3rd party software, whether it was upgraded or not.

In essence, they need to know what you fixed and your baseline is.  Particularly in the world of Java, there can be enough conflicts and issues, that a wise company should keep a running tally of what servers are running what versions of the JVMs and other components.

Some other specific answers for your questions:

Should we list vulnerabilities fixed in Apache Httpd? Or enough link to Apache site?

A link would be a kindess.  Don't clutter up YOUR release notes with other product's details.

Should we manage the list of 3-d party software with versions?

It should be available somewhere, I'm not sure that it has to be in the release notes, but if not, then it should be on your website somewhere.

What about our internal security vulnerabilities? Should we list the list of fixed security vulnerabilities? It may danger those customers that will not upgrade to the latest version.

Keep in mind that a failure to disclose known vulnerabilities could be seen as a legal liability. This is one for your lawyers.  IMO, telling customers so that they know why a security fix is so important is more outweighs the value of obscuring it for the safety of those that can't upgrade fast enough.  That said, you don't have to say "if you X, Y, Z you'll get admin privileges".  Saying "severed vulnerability in access control system" should be good enough.

How should we announce about security vulnerabilities? Should we add our vendor to CVE database http://cve.mitre.org/ and create new CVE each time we found it? Or enough to list our internal bug number?

I'm not really sure what you mean by "our vendor" - I personally wouldn't register a 3rd party for CVE findings without agreeing with them on it.

Should we add to CVE database only vulnerabilities that were discovered by our customers? Should we add to CVE database also vulnerabilities that were discovered by QA?

I have yet to hear of any vendor using CVE for internal test/fix documentation.  I think if you found it first, linking to your own repository of fixed bugs should be fine, but I haven't made that much commercial software.


Can a corporate proxy intercept HTTPS traffic if it doesn't control the certificate store?

In general no they can't. If they could then your ISP (and anyone else in the middle) could intercept your HTTPS traffic making it entirely pointless.

They can intercept the traffic but your device should detect the invalid cert and notify you. In theory a corporate with their own CA could MitM you seeing as you would likely have their root cert in your device. But this would risk their CA trust being revoked.

You also need to be careful if ever asked to install corporate provided software on personal devices.


Is there anything that a regular user can do to help remove fake websites?

I think you've exhausted most possible solutions. What I suggest though, it's using adblockers on your preferred web browser so you won't encounter these ads anymore, but this still doesn't solve the actual issue.


Make sure signed message can't be reused over IRC chat

There are four major approaches to this sort of problem, which can be combined to get more desirable security properties.

Cache the received messages. In this approach you keep a list (of the hashes) of all received messages. If you find a message in said list, you discard it as a replay. The obvious problem here is the amount of storage needed.
Use time-stamps / expiration. In this approach you add a time-stamp / a time-window or an expiration time to your messages. If they are received outside of the agreed upon window they are discarded. The disadvantage here is that if the attacker is fast enough he can still replay and you need to have a relieable clock. This can be effectively combined with the first approach.
Use sequence numbers. In this approach you add a sequence number to your messages. Messages are discarded if their sequence number is lower than the expected value. The obvious disadvantage is that state synchronisation is required.
Use challenge-response. In this approach the client sends an unpredictable challenge to the server, the server includes this challenge in the message and the client keeps the challenge white-listed. As soon as a pending response to an open challenge is received, the message is accepted as valid. As soon as a valid challenge has been accepted the challenge must not longer be considered valid for future use (ie discarded). The obvious disadvantage to this is that the parties are required to be on-line, ie exchange messages somewhat symmetrical and in a timely manner.

For your system, it sounds like the minimal synchronization from the first two approaches offers what you needs.
TLS uses the third approach for the bulk data transport and something like the last for the handshake.


You are correct.  The update statement containing the single quotation mark would be broken due to the termination of the name's value and the ad hoc nature on the update.  It is surprising that errors aren't occurring since the extra text after the closing of the single quotation isn't valid SQL.

I have set up an example of both of these cases (as SELECTs since it is easier to set up as an example) which you can find here.

It is doubtful that you don't already know this, but persistent XSS is a fairly severe vulnerability and if you are curious, some of the impacts are highlighted well here.


Can we print cardholder data under the PCI DSS Compliance framework and stay compliant?

It would only be allowed if you are compliant in other areas.

PCI DSS doesn't just cover digital storage of data, but also the transmission, physical storage and destruction of data.

How does the agent get the card holder data?
How is the data go to your printer?
How and where is the data stored for three days?
How is the data destroyed?


What are the risks to a network if a single computer is compromised?

Without a defense in depth security strategy, once the perimeter defense of your network has been penetrated through your compromised server there are a few threats to the rest of your network.

The vulnerability exploited by the attacker could be available on other machines on your network, allowing an attacker to move to another machine with ease.
A poor access control or authentication scheme to other machines on the network could allow an attacker access to those machines or unauthorized use of service. i,e. Intended for ease of use, A web application server that will gracefully accept any kind of traffic from the compromised machine.
Malware could be present on the compromised server, and may even propagate via a network vulnerability itself. i,e. a worm.

To answer your second question, given that your server has been compromised; The potential is there. Any information that you would like to keep the Confidentiality and integrity would best be placed on another machine with limited access. I would recommend some kind of defense in depth strategy. Or a firewall with well configured policy and traffic monitoring. Snort is a free network based Intrusion Detection System if you want to take it up a notch.

Risk is the calculated cost of a threat agent carrying out an attack on asset. (I offer this definition for completeness because some people use risk and threat interchangeably.) Risk = (probability threat will occur) * (Value of the asset).

A threat is the potential for a vulnerability to be exploited by a threat agent/attacker. (Note, acts of god are considered threats, and their risk should be accounted for!)


How is Token Based authentication stateless?

There is only one private key that is used to sign all tokens. So the key itself is not a server state.

Yes, off course you need a database with user data, like ID and username. But having a database to store permanent data does not make you stateful. When we talk about stateless servers, we mean that there is no session state stored on the server. But off course there is still loads of data about users, blog posts, products or whatever.

Also, since the token is signed by the server you do not actually need to check with the database that the user info is correct on every request. The server makes sure the data is correct when it signs the token, and after that the signature verifies it.


How to store passwords in database so that they can be retrieved?

The normal mechanism for a password manager is to have some sort of "master key" and encrypt the data (symmetrically) with that key. The master key, in your case, being derived from the master password through proper password hashing (so it becomes, in this case, password-based key derivation). So use bcrypt or PBKDF2 to turn the user's master password into a key K, and keep all the data for that user encrypted with K.

Making that as a Web application is of questionable wisdom. Even if you do it all client-side in JavaScript, that JavaScript is still code sent by the server, and code that sees all passwords for all users, so the server becomes a very sensitive and juicy target (if the server goes under hostile control, that would turn into an orgy of password theft).


How can SEC_ERROR_REVOKED_CERTIFICATE in firefox be further examined?

General Troubleshooting:

https://www.ssllabs.com/ssltest/
May or may not include a statement about the trust store status of the certificates in the chain.

Cheating:

Manually check the news & figure out that the certificate authority that created the certificate was distrusted by mozilla starting with the Firefox version in question. In my case, it was StartCom/WoSign.

https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/

Manual checking:

Manually extract the mozilla trusted certificates of each channel from hg.mozilla.org e.g. using
https://github.com/curl/curl/blob/master/lib/mk-ca-bundle.pl
openssl verfiy -verbose -CAfile ca-bundle-channel-xyz.pem
compare result for different channels mozilla-release / mozilla-beta

Note: This only helps for completely removed roots - however mozilla has a special rule about the notBefore date in place for StartCom, which will not be visible this way.


In a content security policy header: Should the url's be quoted or not, and is there any security implication to this decision?

The standard clearly defines the syntax. In section 4.2 it contains the following:

source-list       = *WSP [ source-expression *( 1*WSP source-expression ) *WSP ]
              / *WSP "'none'" *WSP
source-expression = scheme-source / host-source / keyword-source / nonce-source / hash-source
...
host-source       = [ scheme-part "://" ] host-part [ port-part ] [ path-part ]
keyword-source    = "'self'" / "'unsafe-inline'" / "'unsafe-eval'"

Based on this URL should not be quoted while keyword sources like 'self', 'unsafe-inline' ... must be quoted. The example you cite where the URL is quoted does not match the standard and is likely wrong.

In fact, when trying to use such a quoted URL Chrome will complain:

  The source list for Content Security Policy directive 'font-src' contains an invalid source: ''https://example.com''. It will be ignored.


Is it safe to receive (One Time Password) OTP to the Mobile where the online banking application is installed?

Sensitive services' OTP to a mobile is not a good idea. Banks should use hardware OTP or other else.
The typical attack vector for OTPs are three types.
Gaining control of the phone
Well. Literally.
Mobiles, though not so often these days, are easily compromised. Especially, Android applications can freely access the SMS messages(of course with permission).
Exploiting the SMS spam block feature
Most carriers now support automatic spam block, which blocks spam before entering user's phone. Users can log in to the spam control system, set spam numbers, and view spam SMSes.
The attacker uses credientials from breached data, sets the target(ex. bank)'s number as a spam number, and successfully gain OTP data from the spam control system.
SIM Swap/Copy

One particular vulnerability that has gained popularity with hackers is SIM card fraud. This is basically an attack that essentially dupes your telco into swapping your line of communication to a different SIM card that the hackers have in their possession.
This allows a culprit to take over your phone line. Every time you call your GSM provider with any sensitive request, they’ll ask you for some personal data that helps them identify you as the true owner of the line. This is where hackers come in. Armed with personal information on you, a fraudster has the ability to request a SIM change.
Source: https://www.standardmedia.co.ke/business/article/2001296918/sim-card-fraud-why-it-hurts-when-it-hits


How to check if redirected site like OAuth is genuine?

All of the advice provided on the question you linked is already sufficient to verify the login process even when an external provider is used. You just have to repeat the process on every page you're redirected to.

If you're worried about homoglyphs or typo-squatters, then you need to just check the certificate in a little more detail. Most web browsers (desktop browsers, at least) have a feature that lets you see all the pertinent details of a website's certificate, most importantly including the organization it was issued to and information about the issuing Certificate Authority.

If the certificate is valid for the given server or domain, issued to an organization you trust, and issued from a reputable Certificate Authority, then you can be reasonably assured that you're not dealing with some sort of spoofed server.

Sure, attackers can use homoglyphs or typo-squatting to make their server/domain look like it has a name your bank might use. But they'd have to go to great lengths to get a verified certificate that actually looks like it was issued to your bank from a reputable CA. If they really can get that far, no amount of verification on your end is likely to spot any problems.

Come to think, nearly every check that you might manually do on the site or it's certificate (at least, any check that would be "user friendly") is already being done by your browser. So, unless your local system is already compromised (at which point it really doesn't matter if you're actually on your bank's site or not anyway), there's not likely anything about an attacker's site that you'd find by doing any extra checks which wouldn't already be red-flagged by your browser.

Just keep an eye on that "lock" icon, make sure there's no warning signs (green "Extended Validation" certificates are ideal, but strictly optional) on every page, and you should be fine.


Is it possible to recover a lost passphrase for a private key file?

The whole point of having a passphrase is to lock out anyone who does not know it. Allowing it to be recovered would defy the principle and allow hackers who get access to your certificate to recover your keys.

So no, there is no such thing.

What you should do is declare the keys as lost to the issuer so that they revoke your certificate. Then, you have to create a new one from scratch.


You can do this with BURP which will create a fake SSL certificate that the application will probably accept.  If the application is using certificate pinning,  then it becomes more difficult,  you'll have to patch the application in quesiton.


Security implications of stolen .git/objects/ files

Should I worried about it?

Worried? No, of course not.
You should be absolutely terrified and have nightmares about this.
Having stolen .git directory means the attacker have the current and past source for the production server, all history of all code since the start of the repository. With that, they can reconstruct your infrastructure, and do a white box testing against the code.
They will be looking for remote code execution, file inclusion, and SQL Injection right now. And your developers must review every function handling user supplied data (cookies, parameters, URL queries, etc) for any possible vulnerability.
You did a good start by denying access to .git on the servers, but your work is just starting. Your code is now known to attackers, and they are inspecting the code for vulnerabilities. If any time someone hard-coded credentials on the code and commited it, the attacker have that password.
Things you should do:

full code review from a reputable company
consider using a Web Application Firewall
install IPD/IDS (Intrusion Prevention/Detection Systems)
change every single database password
rename the database if possible

Be prepared to fight fine-tuned targeted attacks.


What security requirements do you have for Domain Administrators?

Having worked in both Public and Private sectors as an Info Sec guy I have had the opportunity to see how many organisations approach this and here are some of my observations;

Do you require/support Smart Card Authentication?

I have yet to find an organisation that has deployed smart card auth.

Restrict logins from a particular workstation?

This should be a basic building block, but many sites still fail to restrict access in this way. Further to this, specific accounts that require admin privileges should also be restricted to the specific servers / workstations required. Overly permissive rights can lead to domain compromise.

Require more complex passwords for Administrator accounts?

One site had a fantastic approach to this, they used a long pass phrase for the admin accounts. This served two aims. One - It protected against brute force attacks (who is going to have a dictionary or hash table for a fifteen word sentence?) and secondly it was used to stop the support team from giving the password out on the phone, as it would be obvious they were doing so. That team had a long history of passing out the admin passwords to stop them from having to leave their office and visiting users!

The use of a different computer, or VM for administrative tasks

The use of a management VLAN or other segregation is a good approach. Taking sensitive traffic and access away from the corporate lan is a start.

You should also have an approach to address the use and update to management tools. Deprecated management tools can lead to full domain compromise and a prolific on internal networks. How many times have you thought to patch your 'HP Management Service' or even turn it off? How many remote connection tools do your support team need? I have been on site where Terminal Services / VNC / DameWare and other remote tools were all in use on the same network for the same servers!

So take away here would be to review your approach to the use of management tools, disable those you don't need, reduce overlap of tools used to complete the same task and patch those you choose to maintain.


Resources to learn about memory allocation & security

Buffer Overflows might be what you are trying to refer to. Once you figure out exactly what it is you want to learn, you may want to build your own testing environment to observe how it works. DVWA is a great place to start with that.


Is e-mailing personal information significantly riskier than transmitting the same information another way?

Hopefully the mail traffic is encrypted via tls, but unless you administer your own mailserver there is no way to enforce this. To be shure your data is save you have to use pgp/gpg, bot many companies think that is too complicated for them.
You must decide if you really want to do business with them if they are not prepared to safeguard your data.
As a compromise maybe you can send a password protected zip file und exchange the password via a separate channel, e.g. a telefone call.


block changing IP addresses on port 25 SMTP

Try to block the IP at firewall level, use DROP not REJECT. Monitor, if he does it again, add that IP too.

They are probably scanning for an open relay or a way to use your mailserver as a relay for spam. Don't panic because these scans are quite common. You can try to look for IDS solutions to automatically block this behavior if it bothers you too much.

Should it be that it is not a break in attempt with spoofed IP's then it is probably a DDoS and you will need to contact your ISP. (If they want to get into your system they will be using real IP's since they want a response)


Serial Number / Thumb Print of Digital Signature/Certificate

None of them. A digital signature does not have a recognizable identifier.

You are seeing in the two forms the serial number of the certificate. The serial number is a unique identifier assigned by the Certificate Authority to the certificate and the thumbprint is a hash of the certificate data.

A signature contains a message digest of the signed data (you can see it in form), signed with the private key of the sender. A digital signature has no a identifier but you can know:

the identity of the signatory, because the public key contained in the referenced certificate match with the private key
That the message has not been altered, because it will break the signature


Network address (DNS) translation on Amazon Web Services (Ec2)

EC2 uses 1-to-1 nat, so all of the traffic addressed to the public address is forwarded to the private address of the EC2 machine (subject to firewall rules you define).  EC2 machines sit behind a firewall provided by AWS called a security group, which will certainly have an effect on your testing.

What you are proposing to do almost certainly violate's the AWS acceptable use policy.  They require notification before doing penetration testing.

Have you considered using local virtual machines, such as VMWare or VirtualBox?


Are there techniques or methods to develop security protocols without side channel attacks?

Avoiding side-channel attacks in protocols (or in general) requires just a few things. Unfortunately, it's often easy to slip up, as it is not always intuitive. The general way to avoid side-channel attacks is to ensure that any behavior that can be monitored by the attacker is not in any way dependent on any secrets which the attacker must not be able to access. A simple example is string comparison. How long a task executes is behavior available to the attacker. With a simple, "unsafe" string comparison function, the time it takes to compare the string is dependent on the number of matching characters.
In order for this question to be answerable, you have to define where your attacker is. Are they on the client, running an untrusted process next to one handling sensitive data? Are they on the server? Are they simply monitoring the traffic going back and forth between the client and server? Knowing this will allow for a more precise answer. Since there are a large number of papers detailing side-channel attacks, knowing your precise threat model is even more important for suggesting papers to read.
On the computer itself
If the attacker is listening on one of the computers handling sensitive data, avoiding side-channel attacks is harder. You must ensure that memory accesses and computations on secret material occur without regards to the value of the secret. This means avoiding certain common optimization techniques that take "shortcuts", skipping unnecessary operations. Unfortunately, doing this correctly often requires an understanding of the underlying CPU architecture. Sometimes, under specific and obscure circumstances, the same instruction may take longer based on the contents of the secrets. An example is any instruction accessing memory. The speed at which it accesses memory depends on whether or not the data being accessed is in the cache, opening up the possibility of cache-timing attacks (such as Flush+Reload).
Avoiding side-channel attacks that exploit the behavior of the cache requires both an understanding of the algorithm being processed itself, as well as the architecture the algorithm is running as. One of the most-studied examples is AES, where a common optimization stores S-boxes and round keys in the cache. This is very fast, but vulnerable. The solution is to implement it using bit-slicing.
Over the network
If your attacker is simply monitoring the network, the solution is much easier. Generally, unless the network is exceptionally low latency (a very, very fast local LAN), the timing required to perform side-channel attacks is often lost in the noise on any regular network. An attacker very close to the server (its own router, a router very near it) may be able to obtain more precise timing information. This means that, in general, timing attacks over the network are not a problem, but it doesn't hurt to avoid the risk anyway. This can be done in the same way as if the attacker is local. Simply ensure any sensitive computations are constant-time. String comparisons should take the same amount of time regardless of whether or not all the characters match, some of the characters match, or none of the characters match.
A common example
As mentioned a few times before, one of the most common mistakes people make is to use optimized string comparison functions on secret strings.
An unsafe string comparison function. It will immediately return an error as soon as the first non-matching character is found. Timing how long the function takes to return false will allow an attacker to brute-force the password one character at a time. It is suitable only in situations where the attacker cannot determine how long it takes for the function to return.
bool password_check(char *s1, char *s2, int len)
{
    while (len--)
        if (s1[len] != s2[len]) return false;

    return true;
}

A fairly safe string comparison function, suitable for use in high-latency networks where nanosecond-level timing information is not available to the attacker. It checks the whole string and keeps going even if it knows the strings do not match. It will take a constant amount of time to check if the passwords match.
bool password_check(char *s1, char *s2, int len)
{
    bool mismatch = false;

    while (len--)
        if (s1[len] != s2[len]) mismatch = true;

    return !mismatch;
}

Note that this is constant-time in theory, but an attacker able to do extremely precise monitoring may still be able to gain some information from it. For example, setting mismatch to true involves, at the least, writing 0x1 to a register. Setting it to false on the other hand is often optimized by XORing a register with itself, which sets it to 0x0. Whether or not this is done depends on the compiler, so a highly sensitive string checking implementation should be done in assembly, with a good knowledge of CPU optimizations. If it must be done in a higher level language like C, you must understand how it will be compiled into assembly and design it so that optimizations will not result in a side-channel attack.
A very safe string comparison function. It uses bitmasks to determine whether the strings match. It is suitable for use when an attacker can precisely time how long it takes the function to return.
bool password_check(char *s1, char *s2, int len)
{
    char mismatch = NULL;

    while (len--)
        mismatch |= s1[len] ^ s2[len];

    return !mismatch;
}

Another common way to avoid side-channel attacks when comparing strings is to hash them, and compare the resulting digests. A hash function should take the same amount of time for input of a given size regardless of the contents of the input. The output will be of fixed size, and can be safely compared with an "unsafe" comparison function.


It depends on if you're using "Enterprise" or "Pre-Shared Key" (PSK).

If you're using "Enterprise", then one of your options is to use EAP-TLS, but there are other options like PEAP.  These are typically the only two you will see in implementation, although there are plenty of others.

With EAP-TLS, check out EAPoL, and this diagram really helps to clear things up.

With PSK, there is the four way handshake that you mentioned.

In summary, you summarized two separate ways of establishing a connection with a WPA-TKIP enabled WAP.  Hope this helps.


How secure is a server's .htaccess file?

Would access need to be gained to the server in question?

To read the .htaccess file, yes, assuming the server is properly configured everything else running on the server is secure. Most default apache installations have a rule that files starting with .ht will not be served statically. It could still be served by a buggy application on the server, like a PHP script that passes user input directly into file_get_contents .

  Can an .htaccess file leak information in some way?

Yes, it can leak anything that is in it. Basic information like the path to your web root can be found in it. Perhaps an open redirect could be discovered. Some applications have a .htaccess file set environment variables containing database credentials. In reality though, if someone is able to get access to your .htaccess file, you probably have bigger problems.


Getting in to the security side of things

Security is a very very large field. What specific area of security are you interested about getting into?

It seems like you have a lot of experience in the administration world. You can use that as a starting point to get into security. Study up on hardening servers, networks and what have you. I know that Cisco and RedHat have security certifications about hardening their specific products. You can look into that.

If you like development work, learn about how to develop secure applications. Read up on common attacks like XSS, SQL injections and buffer overflows and try to minimize them in the code you write.

If you want to get into the offensive side of things, learn how to exploit the common vulnerabilities. There are many resources available that allows you to practice including hackthissite that allows you to hone your skills in a safe environment. Get familiar with the tools in Kali Linux/BackTrack, there are many useful ones in there. Pick up a scripting language like python or ruby, this will be immensely helpful when you need to automate task or write proof of concept exploits.

Certification wise, CISSP is the industry standard. OSCP is an excellent hands-on certification as well. I heard good things about the various SANS certificates but they are costly. Very costly.


About the AES algorithm key and ciphertext

A) AES keys are comprised of binary bits, not strings of characters.   They should indeed be random, and no other properties are required. However, this does imply that they should be random bits, and not ASCII characters.

B) If you decrypt ciphertext with an arbitrary random key, you will get some bytes as the plaintext.   Whether these bytes constitute a valid plaintext depends on your specific definition of valid, but for most definitions of valid, the answer is no.  If, however, you are really asking if it will cause the decryption to fail, then that answer is also no.


How can I prove this site has a huge security weakness?

The password format in the userpassword attribute looks like the standard format used by various unix services, such as the default system password service which stores hashed passwords in /etc/shadow. The format is basically:

$ type $ salt $ hash

In your example, the type is 1, which designates an md5 hash. There are other well-known types, such as various sizes of the sha-family hash functions.

Breaking an md5 hash is almost trivial today, even when it's salted, because md5 is so fast. It's not a hash function which is safe to use for hashing passwords; hashcat and other password crackers can literally hash millions or even billions of password candidates per second.

So this data store service isn't just horrible because it sends user password hashes back, it's even more horrible because it actually uses md5 hashes to store passwords.

To prove to your boss that this really isn't secure, you could download hashcat and a few password lists (you can easily find them online), and then run hashcat on a computer with a very powerful GPU on all the passwords you get from the service. Make a note of how many passwords hashcat can crack (without looking at the passwords themselves - they may reveal private information about the people who chose them, and you don't want to actually know their passwords), and inform the people whose passwords were compromised that they need to choose a new password. You'll probably need to get permission to do all this first, because depending on where you live and work, this might actually be considered a malicious attack, or even be illegal.

Aside: If you were stuck on using this service even after voicing your misgivings, I'd suggest that setting up an automated password cracker that runs without human intervention and informs people (by sending them an e-mail) when it manages to crack their password would be a way to protect your users from this kind of bad design. It would help to weed out weak passwords and increase the amount of time needed by a real attacker to crack passwords.

Edit: Zach pointed out that the aside isn't common practice and shouldn't be attempted by someone not able to assess the risks. I fully agree with that. At the very least, if you did something like that, you should have management okay it.

Still, NOT doing this doesn't make the resulting system more secure. It's the equivalent of sticking your head in the sand out of fear that if you actually did something to improve password security, it might backfire on you. We know that people choose bad passwords, and we know that md5 is not a good way to hash passwords. If we can't change these two facts, and we are in a position to weed out weak passwords, then we should probably do it to make our users safer.

One important reason this isn't seen much, or even considered much, is that we usually aren't in a position to implement it. Good systems don't use fast hash functions to hash passwords, and we usually don't get access to the whole hashed password database.


How to avoid using System.String with Rfc2898DeriveBytes in C#

The .NET Core team specifically recommends against using SecureString for new development. See the SecureString documentation:

  We don't recommend that you use the SecureString class for new development. For more information, see SecureString shouldn't be used on GitHub.

as well as the team's reasoning on GitHub:

  Motivation

  The purpose of SecureString is to avoid having secrets stored in the process
  memory as plain text.
  However, even on Windows, SecureString doesn't exist as an OS concept.

  It just makes the window getting the plain text shorter; it doesn't fully
  prevent it as .NET still has to convert the string to a plain text
  representation.
  The benefit is that the plain text representation doesn't hang around
  as an instance of System.String -- the lifetime of the native buffer is
  shorter.

  The contents of the array is unencrypted except on .NET Framework.

  In .NET Framework, the contents of the internal char array is encrypted.
  .NET doesn't support encryption in all environments, either
  due to missing APIs or key management issues.


The answer is actually included in RFC 4630 and various later ones. It looks like 2003 was the last year when other encodings were relevant. These days UTF8String (or potentially PrintableString) are the answer.


Best Practice for MFA on Root AWS Accounts

Here's how I wrote up a solution to this:

The Vault product from HahsiCorp allows you to log all access to any credential, and it supports TOTP hashes in such a way that it'll permit you to read the current value but not the secret key. To use root access, get the current token from Vault.

To ensure that you don't lose access, make good backups. To ensure that your backups aren't compromised, split the master decryption against the appropriate number of individuals in your organization and encrypt that to PGP keys on hardware token.

In this way as long as a Vault instance is running, any authorized person can use the root credentials and you'll know who did. Actually getting the root MFA secret would require collusion among multiple people.


What does a common workstation setup look like for pentesting and vulnerability research?

It sounds like you are confusing your work environment with your target environment.

Which OS should you work from? There are far more useful tools in Linux than in Windows. Use Linux (or even a penetration testing distro like Backtrack) as a work environment. If you say that you could roll your own security tools (and why would you when there is a community of developers pumping out quality tools?) then it should not take long to get up to speed in a Linux environment.

Which OS should you become proficient in testing/penetrating/audit/fuzz? That is up to you. The technical side is as doyler says: you can always run virtual machines of either OS. In fact, with only a little virtual machine networking configuring, you could create your own test network with a mix of OS'es.

Which OS should you target from a learning/gaining expertise perspective? It depends on where you want to go with it. And, you might need to provide more details on your goals for us to weigh in on that.


Extract AES key by comparing plaintext and encrypted data

No.  This is known as a known-plaintext attack (or a chosen-plaintext attack if you are not only aware of but can select the plaintexts), and is a type of attack that AES is highly resistant to: there are no known attacks of either type that are faster than brute force.

If you've got access to the encryption coprocessor (and a good electronics lab), you may be able to perform side-channel attacks to recover the key, by analyzing the activity of the coprocessor as it performs encryption.


To sufficiently protect against KRACK is patching the client, the AP, or both, required?

To fully protect your network, both the device and the access point will need to be patched:

  Source: https://www.krackattacks.com/#faq

  Finally, although an unpatched client can still connect to a patched
  AP, and vice versa, both the client and AP must be patched to defend
  against all attacks!


Why do people warn of putting unknown USBs in your device

A USB "thumb drive" could be a keyboard interface in disguise.  A popular tool called Rubber Ducky works like this:

"While it appears to be an innocuous USB thumb drive, when it is plugged into a computer, it instead registers itself as a USB keyboard on the system and fires off a keystroke payload at lightning speed." (Tutorial)

Most commonly an encoded PowerShell script is typed in and run, creating an implant on the system which will then call out to the attacker over the network.


Protected APIs for public clients without end-user authentication

I think you should refere to the current draft of OAuth for Browser-Based Apps:

9.3.  Client Impersonation
As stated in Section 10.2 of OAuth 2.0 [RFC6749], the authorization
server SHOULD NOT process authorization requests automatically
without user consent or interaction, except when the identity of the
client can be assured.

In my understanding, it is currently not recommended to not show a consent page, what is your plan, if I understood your question right, since the consent page is what protects public clients against client impersonation. This applies indepentent of the used grant type or the extension (e.g PKCE) you use.

If you would have previously  processed an authorization request of a specific client (your description reads like you did not) and you use fixed redirect URIs, you could use the redirect URI to identify the client:

If authorization servers restrict redirect URIs to a fixed set of
absolute HTTPS URIs, preventing the use of wildcard domains, wildcard
paths, or wildcard query string components, this exact match of
registered absolute HTTPS URIs MAY be accepted by authorization
servers as proof of identity of the client for the purpose of
deciding whether to automatically process an authorization request
when a previous request for the client_id has already been approved.


Should I check Host header or ServerName for CSRF defense when serving behind proxies?

According to OWASP Cheatsheets, both are fine. I would object checking X-Forwarded-Host, as it's not a forbidden header.
You can do the following check, and it will be compatible in most cases: ( $Origin or $Referer ) == ( $Host or %ServerName% )
As for the load balancer part, if you're considering deploying a commercial CDN for your application, the following configuration may be usable (it's based on Apache HTTPD, other servers would have different config directives):
UseCanonicalName on
<VirtualHost *:*>
  ServerName app01.example.com
  ServerAlias app01.source.example.com
  ...
</VirtualHost *:*>
...

And configure the DNS servers to resolve app01.example.com to the CDN, and point the CDN to app01.source.example.com. This way, when an HTTP request arrives at your server, Origin/Referer will match ServerName in your server-side CSRF defense codes.


Required skills before jumping into vulnerability research

Well vulnerability research implies that you have a really good knowledge of how thing work. For starters I think that knowing assembly and C is the best way to start. A really good assembly knowledge will help you with reverse engineering and finding vulnerabilities.

Personally I'm learning really hard assembly language and C. You'll also need practice (a lot of practice) in a lab environment. Personally I think this 3 books will get you really stared:

1) Shellcoders HandBook

2) Hacking The Art of Exploitation 2nd Edition

3) Gray hat hacking


Using Private Browsing mode while connected to organization's network

As others say - Private Browsing is a protection for your workstation/laptop - great if you want to clean it because it's used publicly.  Not great for eluding your network admins.

The company you work for does have the right to set a policy for how it's resources are used, and monitor that employees stick within the policy.  The analogy of a phone system is apt - you've reset your "phone", you haven't erased your phone bill which shows every number you called.

Depending on configuration, your company can see what IP addresses you visited, what URLs you requested, the traffic sent between the sites and you, content transmitted between the sites and you, and get a rough sense of for how long you were visiting the sites.  The sites you visit do represent a security risk, and the company has a right to monitor and protect itself from that risk.

Practically speaking, it's rare for a company to scrutinize employee by employee.  Collecting the data, sorting it for each employee, and going through it in details is just way more work than a company of any size wants to consider.  In a big company, it's like finding a needle in a haystack, in small companies, the one guy who can do this is just too busy.

Generally, you have to do some or all of the following for this to come into play:

do very poorly in job performance - to the point where they wonder what you are doing, because it clearly isn't work...
have a major security issue - if you get hacked or get a virus, they will fix it, research why it happened and try to prevent it in the future.  That extra scrutiny can bring on questions of why you were on a social site if the company policy prohibits it.
visit sites excessively, and compromise availability of resources - if you are streaming Hulu, Netflix, YouTube, etc for the entire work day, you are limiting bandwidth for legitimate use.  When the executive says "why is this so slow?", you don't want to be the reason.

In all honesty, I find the best answer to be - if you want your behavior to stay private, don't do it at work.  The computer for work was given to you for work.  Generally some polite social browsing in limited scope is not against the rules, if it doesn't impact your work... but the point of the computer they gave you wasn't for your personal enjoyment.  If your privacy is important, do it at home, or pack a personal device with net access - it's getting easier and easier with smart phones and tablets to get off the company network entirely.


Encrypting a symmetric key or Small File using TPM and Windows (TBS?)

I was able to do this fairly easily with jtSS http://trustedjava.sourceforge.net/index.php?item=jtss/readme

After installing the windows service,
jtt create_key to create a key, then jtt seal to perform the sealing.

example commands:

>jtt create_key -u 00000000-0000-0000-0000-000000000000 -t storage
>jtt seal -i message.txt -o message.enc -p 1,2,5 -u 00000000-0000-0000-0000-000000000000
>jtt unseal -i message.enc -o out.txt -u 00000000-0000-0000-0000-000000000000

-p specifies the PCR registers, and these represent the different values of the machine state (bios, boot devices, etc)
-u is the UUID of the key being used.


You are the author of the website or otherwise server-side code — you get to decide what is a valid query string or not. Why would you concern yourself about what is acceptable? Your first responsibility is to design your API to behave as expected and be secure, not to offer « courtesy » in accepting any kind of input. Regular users are on the contrary keen to know how you defined the API, and adversaries are keen to know what you are missing.

It is perfectly acceptable, and even it is a strong requirement to validate user input, always. The video explains a problem with a bug, in that the author of the snippet did not defend against an unexpected behaviour of PHP. A string was expected and an array was passed, input was not validated, problem occurs.

Best practices always include that if you are taking input from external sources, you must validate, sanitise or otherwise verify it before doing anything with it, according to the rules you have set for your API.

P.S.: for those interested, this is the video referred to by OP: video


Squid/Squidguard is kind of the de facto standard for this kind of thing. It's free and runs on Linux. This can work if your intent is to filter all traffic on the border of your network instead of installing a filter on each machine.


Web servers with different risk models in same network

Isolation is never bad. In a very generic overview sense, imagine a submarine. They are designed with the knowledge chances are stuff is gonna blow up in, on or near them. That is why they are compartmentalized allowing a ruptured hull to only floor 1/16 of the submarine. Not coincidentally, submarines are also pretty good at not sinking (and staying sunk).

Presumably your two web servers have different remote desktop (or telnet or SSH your choice) credentials and if they don't, that's already a major issue. Generally, a web server containing 7/10 level secret data (I am going to assume at least quite personal info if not financial or tax related or health info) the password for that machine might be much better thought out, for example, a 16 character crpyto-randomly generated password. At least that is what I might do. Alternatively, my 2/10 secrecy web server might have a easy to remember password cause well, we are humans and lazy. For example, maybe username is admin and password is adminCompanyNameSecret. Still not easy to guess, but much more predictable than a crypto-random password.

I hope you see where I am going here. Naturally as administrators, we will practice more relaxed security precautions on servers that are of a lower value target. The issue is as I am sure you know and realize, once an attacker can get on server A, getting to server B (secure server) on the same network will be much easier than getting into server B from off network.

Therefore there is nothing wrong with keeping both servers on the same network and as you said, it might make sense from an architecture standpoint, but if you do you must do the following:

Treat BOTH the 2/10 and 7/10 secrecy servers as if they were 7/10 secrecy servers. Ensure both are completely up to date on all OS updates, follow good practice with physical access and security, crypto-random passwords and unique usernames. Ensure only a limited few know the passwords etc. If you follow this, you are just as safe as you isolated the two servers. If you treat the 2/10 as a 2/10 secrecy server, you pretty much just degraded the value of the data in the other server to 2/10 as well.


How secure would this method be considered for password storage

It's generally a bad idea to invent your own security algorithms. As you've already said, you don't know if this is secure. You may believe so, and maybe you even find somebody who agrees with you. But that doesn't really mean much.

There are established solutions like bcrypt which have proven themselves both theoretically and practically over a course of many years. We can be pretty confident that those are in fact secure. So why not take advantage of this and use bcrypt?

Regarding your own algorithm:

First of all, I don't see why you would limit the user to only 6 to 24 alphanumeric characters. This makes it impossible to strengthen the password with special characters or use a long passphrase.

The mt_rand() function produces weak random numbers from low-entropy sources like the server time and the process ID. The PHP manual explicitly points that out. A total of 8 bytes also isn't too much.

I cannot comment on whether your hashing scheme is sound, but given that stock PCs can calculate billions of SHA-256 hashes per second, 16,000 rounds again aren't much.


How should we implement responsible discovery program internally only for our organization employees?

The best way is recognition - after a security issue has been identified or fixed send them some email award template and CC in their manager. The value to them is being able to refer to this item in pay reviews and discussions with management.

Outline what is considered a security issue and what isn't to try and filter noise.

Add another level to this with a reward system - every month or quarter provide an aware to those that have reported security issues. Base it off reporters number of issues, severity of issue report or at random. Ensure that comms go out either company wide or department wide about the winner of quarter and month + what they received as  reward.

Ideally what you are trying to do is build up security champions in the company so not only do they report issues but influence those around them to do it.


Is denying write access an effective way to stop ransomware?

Can be done? Yes, it can.

It is worth? I doubt.

It is effective? Probably, probably not.

If you set the folder as read-only using your normal user account, ransomware can revert it to read-write, and encrypt your files. The read only folders will be in your way every time you want to save anything.

If you use the admin account to do that, you must start an elevated Windows Explorer every time you want to save anything on the protected folders. And it's easy to forget to return it to read-only after writing.

If you intend to put yourself on a restricted system to prevent ransomware, implement Windows Application Whitelisting to only allow the execution of approved programs. Any ransomware you not add to the list will not be executed.


How did the Tweetdeck XSS vulnerability work?

This attack worked for a very simple reason - TweetDeck did not sanitize the user input at all under some circumstances. The attacker did not discovered a clever way to fool the XSS filter. Instead he found a a way to turn it off. As your quote says:

  So, I started to play around, and discovered, that the Unicode-Heart (which gets replaced with an image by TweetDeck) somehow prevents the tweet from being HTML-escaped.

Apart from the obvious fact that the person who wrote the code was not very good at his or her job, we can only speculate why a unicode heart would turn the filter off. My guess is that they wanted to render the heart with an <img> tag, and that the tag got caught in their own filter. So they did an easy solution and just turned the filter off when they needed to insert HTML into a tweet.

But that is just a guess. To know for sure you would have to ask them, and I doubt they would answer.

So all he needed to do after the discovery was to write some JavaScript to do the automatic retweeting, slap a heart at the end, and tweet it. If you have enough followers who are using TweetDeck, it will spread by itself from there.

Some good non-technical explanations:

"The Thought Box" blog
Computerphile video


Is it practically possible to spoof a WLAN access point?

What you are thinking of doing is incredible similar to an existing attack known as the karma attack, made popular by the super fun Wifi Pineapple.

The basic principle behind the attack is for the attacker to setup an AP that responds to the wireless probe packets clients send out when attempting to connect to a previously trusted AP. By responding to each individual packet on an individual basis, the attacker can force the client to connect to their rogue AP.

When combined with a deauthentication attack, this is an incredibly effective tool for performing MITM attacks.


Password database vs flat encrypted file

By sharing passwords, they are already 'compromised', which might be an ok risk for your environment. You know you have to change ALL shared passwords, even the encryption key whenever you lose a member of the team, so there is not going to be a lowered workload by using either method.

What you are really talking about then is simply a 'user logistics' issue. There is no 'security' issue here to discuss, as long as passwords/keys are changed when someone leaves. Use the tool that fits your team workflow best.

As a side note, I'd REALLY like to suggest you limit the number of shared passwords to an absolute minimum. I believe LastPass allows you to share credentials with another user without them being able to read what the password is (works with web logins). Other solutions might be similar.


There are a few things I've seen have good success.

Developer Standards - This would include things like libraries to use, encryption ciphers and strengths to use, information on testing for input sanitation, etc. The key here is to work very closely with the leaders in the development org.

As long as the data is up to date, accurate, and well put together it saves developers a lot of time. This will ensure your developers spend as little time thinking about pre-determined security configurations and can focus on the problem solving they really are there for. This is also very helpful in that it takes new developers less time to really get up to speed.

Hacking Challenges - These can take a lot of setting up, but as schroeder mentioned, challenging developers to solve puzzles can be a fun way for them to learn. You can put up a system that is vulnerable to some relatively common vulnerability, and challenge developers to get some type of data out they are not supposed to do. Which language/platform/os etc. depends a little on what it is your developers code in.

Static Analysis - Develop good static analysis tools, and expose results to your developers. Help them learn to interpret them so they can write more secure code. This is potentially a ton of work but pays off depending on how many developers you have to train up.

Security Champions - Just like with any other topic, some developers are more fascinated by security than others. Find these folks in your various teams, send them specific information, ensure they report strange security issues to you, etc. You could potentially help teach them more advanced use of security tools and give them at least a basic understanding of code auditing so they can help review their team's code. Give them t-shirts, little awards, and other recognition and always, always be sure to THANK them. :)


My ISP blocks incoming ports so I can't even run webserver let alone 'reverse shell', any ideas?

You need a VPN SERVER because ISP does not open port 80 by default so you cannot listen on that port to complete http listen attacks.
I recommend you to first try free VPN server and then you can check whether port 80 is open or not by going to Here.

If you are using router you need PORT FORWARD to redirect request to your machine.
Here is the tutorial you can try.


IT Contractor with domain administrator credentials best practice?

So general best practices first:

Do not use generic accounts (i.e. ConsultantCo) rather use named accounts (i.e. JSmith_Consultant). One for each contractor.
The contractor probably doesn't need Domain Admin. Local Admin on the SharePoint server (and whatever other systems are needed) should be sufficient.
Enable logging on the box(es). If possible, ship the logs to another server that the consultant doesn't have access to for review/audit purposes.
Enable time-based logins. In other words, restrict the user's ability to logon to only the times they should be doing work.

For Meraki MX Appliances:

Similarly, make sure the user does not have excessive permissions, if the Meraki VPN users are not tied to AD, then configure a separate (complex) password for this account as well.
Enable logging, Meraki supports exporting to syslog for reviewing activity.
I don't believe Meraki has implemented time restrictions on VPN access yet, so manually disable the account when not in use (nights, weekends, holidays, etc.)