Can I rely on Operating System (OS) Anti Virus (AV) scanning to scan files shares? I have an EC2 instance with an Windows OS with anti virus installed.

I have a requirement to attach a file share to the OS where the application is hosted. The file share is  Amazon Fsx ( Amazon's native windows file system).

Can I rely on the OS scanning the Fsx file share or should the Fsx have its own file scanning capability?

It depends on the context.

You should consider some things like the following:

what type of files reside there and what can open/execute them
what OS(es) will open the target files
what capabilities your AV has

Explanation: If your files are generated and stored by a similar OS to the one you scan the location with, then it's pretty safe to do so. If the files are from a different OS then your solution is insufficient and will be as good as the AV solution is, which in turn can or cannot correctly detect dangers designed for other OSes than the host one and may or may not have advanced features (like centralized threat detection).


Is steganography a part of "cryptography"? In preparing for a security exam, the prep book I'm reading states:

  In the field of cryptography, the topic of encryption gets by far the
  most attention
  ...
  ...
  Other techniques such as steganography also belong
  in this field, but encryption is the one that attracts the most
  attention for manipulating and protecting information.

I've always thought of Steganography as being completely separate from cryptography and in researching more online, it would appear that I'm not alone:

http://crypto-grapher.blogspot.com/2009/03/cryptography-vs-steganography.html
http://www.dustintrammell.com/presentations/Steganography-Primer/img2.html
https://en.wikipedia.org/wiki/Steganography

So... is the book incorrect? Or does Steganography fall under a broader category of Cryptography?  That doesn't seem right to me...

Steganography, first coined in 1499, does not technically require the use of a cipher or any calculations even though we primarily read about it now in the digital world.

https://en.wikipedia.org/wiki/Steganography

In his 1499 book Steganographia Johannes Trithemius discussed Steganography's advantage over cryptography and by doing so I would say his intent was to clearly differentiate it from the field of Cryptography.

https://en.wikipedia.org/wiki/Johannes_Trithemius#Steganographia

I do think this is one of those topics that goes back and forth fairly often but the general consensus I've seen is that Steganography is not part of cryptography and that it is uniquely separate.

Finally it does appear that Steganography may also be legal in countries which otherwise outlaw encryption.

Personally I would say both are used for forms of secure communications but are clearly different techniques.

BTW: It appears there is a copy of his original book on-line at the following URL

http://www.esotericarchives.com/tritheim/stegano.htm


How to correctly escape a string from an input field, preventing XSS attacks in JavaScript I have a tiny application and I've read a lot about XSS, so I want to sanitize the one input that I have.

When googling, I came across the OWASP guide stating that the following should be used to correctly sanitize the input:

String safe = ESAPI.encoder().encodeForJavaScript( request.getParameter( "input" ) );

I'm quite new to coding so I copy/pasted it to my JavaScript function and doesn't appear to be working.

A rough representation of what I'm trying to do is executable here, the code:

<input name="this" type="text" maxlength="16" id="this" />
<button onclick="run()">run</button>

<script>
function run() {

// how I used to do it
// a = document.getElementById("this").value;

safe = ESAPI.encoder().encodeForURL( document.getElementById("this").value );

alert(safe);
}

</script>

Valid characters for my applications are only the numbers [0-9] and a dot (.).

How do I correctly escape/sanitize an input field in JavaScript to prevent XSS attacks.

I'm quite new to coding so I copy/pasted it to my JavaScript function and doesn't appear to be working.

It might not be working because ESAPI is a library you have to reference in an HTML script tag; it isn't part of core javascript that comes with the browser. ESAPI seems to be available from github, which also contains a README.md file that explains how to load it in HTML. May you missed that part? Your question doesn't say.

Also, note that it should be

var safe = ....

not just

safe = ....

This is important in javascript. You don't want to create global variables and pollute the global namespace if you can help it.

  Valid characters for my applications are only the numbers [0-9] and a dot (.).

In that case, I'd suggest you use a javascript regular expression to see if your input matches these characters, and show an error message if it doesn't. ESAPI seems to be overkill for that. Validating "known good" input is much safer than trying to think of all problematic inputs and removing/transforming that via a sanitation routine. Do something like that:

var validationRegex = new RegExp('^[0-9.]+$');
var text = document.getElementById("this").value;
if (text.match(validationRegex)) { }; // do something when text matches

I don't have all that much javascript experience, so you might want to read up on how regular expressions work in javascript to doublecheck that code. Take care with the dot character - outside of [ ], it stands for "any character except newline" in regular expressions.

Finally, if you're sending your extracted input field data to a server (I'm cleverly assuming that you don't just want to output the data via alert(safe) - in which case you wouldn't need to sanitize it in the first place), it would be much better to sanitize the data on the server, because there you can trust the sanitation. If you sanitize on the client, a malicious user might still send your server unsanitized data.


End-to-end Encrypted Group Chat Considerations I was thinking about building a simple end-to-end encrypted chat with group chat capabilities. Please bare in mind that 1) it's just an experiment to help me know more about cryptography and 2) I'm an humble programmer not a security expert that knows all the cyphers out there and complex encryption schemes.

My first thought was to:

Single conversations (two persons): each client generates a public/private key pair and sends the public key to the server. Every-time someone whats to talk to another person they just have to grab the recipient's public key from the server and encrypt the messages using that key. Later on the recipient can just decrypt them with their private key;
Group Chats: when someone starts a group chat:

A public/private key pair is generated by the user who created the chat (lets call it starter);
The "starter" fetches all public keys of the participants from the server and encrypts the chat's private key with them;
The "starter" sends the encrypted chat private key to each participant;
Each participant can now send encrypted messages (by encrypting them with the chat's public key) and decrypt messages coming from others by using the chat's public key.
If someone is added or removed from the chat, a new chat public/private key pair is generated and distributed using the same procedure above.

Focusing on the group chats: What are the drawbacks of this implementation? Is this a reasonable and secure approach to the problem?

Overall
I would recommend that you use hybrid encryption.
It's more performant than using "only asymmetric encryption" (public-private-key). Some problems could even occur when you encrypt very long messages with asymmetric encryption.
The server should never know the symmetric keys. It's main task is to guarantee the transmission of the messages.
2-party-E2EE
The first "message" between two parties is the exchange of a symmetric key via asymmetric encryption. This is to increase the performance of all succeeding messages (symmetric encryption and decryption is faster than asymmetric encryption).
Mulit-party E2EE
This basically works the same way as the 2-party-end-to-end-encryption. The simplest method would be this:

The admin of the group chat creates a (random) symmetric key.
The admin sends this symmetric key to each recipient of the group via asymmetric encryption.
All further messages are then encrypted & decrypted with this symmetric key.
If a new party joins the group then this symmetric key can be sent to this party as well, if you don't care that these members then also can decrypt previous messages. If you don't want them to decrypt older messages, then the 1. step is repeated.
If a party leaves the group then the 1. step is repeated.

Edit: I should probably also add that there are definitely more details to it, but this shows the basic functionalily.


Detect changes in /boot when using full disk encryption When running a fully encrypted linux system using dm-crypt, the /boot partition has to be unencrypted to boot, as far as I know. I've setup a server that can be unlocked remotely by connecting to a pre-boot ssh server that is running from initrd.

One attack vector I'd like to close is installing a keylogger in the initrd.

I reasoned like this:
I cannot prevent changes to the /boot partition as the adversary has access to it in a hosted environment. But I can detect changes using checksums from within the encrypted system using simple sha512sum or tripwire. Also I can monitor the server for reboot (which might indicate changes).

What mitigation methods come to your mind?

This is exactly the problem that Secure Boot was created to solve. The problem is that if you don't have a chain of trust going all the way back to POST, then you can't guarantee that there hasn't been tampering. (And even then, "guarantee" is an exaggeration).

You can checksum the boot partition at startup; perhaps use the checksum as part of the key for the next step. It's not completely tamper-proof, but without hardware-based crypto integration nothing will be. Just do your best with the tools you have and make sure you understand the limitations.


Why do so many embedded devices use shared keys? Many commercially available embedded device manufactures use the same keys for all instances of their respective devices. This situation is so rampant, a project called littleblackbox has created a catalog of these keys. From their site:

  A command line utility is included to aid in the identification of
  devices or network traffic that use these known private keys. Given a
  public certificate, the utility will search the database to see if it
  has a corresponding private key; if so, the private key is displayed
  and can be used for traffic decryption or MITM attacks.

Having a connection that has been "secured" by a publicly known private key provides the user with a false sense of security (especially if CA signed certificates are used), potentially making the device manufacturer liable (in my non-attorney opinion). So why do they do it? Is there some odd benefit I'm missing? The obvious solution to me would be to generate a key and a self-signed certificate upon the device's first boot.

It is probably easier to manufacture these devices if they can all use the same image. Also, what if the shared key needs to be stored in ROM or a place that cannot easily be updated during first boot?


HIPAA: How am I required to secure PHI database access creds on my web server? Assuming I have a database of PHI that my web application needs to access, how am I required to secure the credentials on the webserver that the web application uses to access this database?

Is storing a standard user/pass combo a HIPAA compliant method, or do I have to figure out something more secure?

Config file example (stored outside web root as dbConfig.something.php)

$phiDb => array(
    'dbUser' => 'webPHIUser',
    'dbPass' => 'webPHIPass',
);

So, according to the HHS security guidelines, a username and password combination is a sufficient mechanism for authenticating an individual.   However... Storing user passwords in plaintext in a config file is not usually a recommended design pattern.  Certainly not a list of every individual user allowed to access the database along with their plaintext passwords.  I am not a PHI/HIPAA auditor, but I would strongly expect that if I were to present this design to an auditor, he might take issue with this.

Some measures that you could take to limit your risk:

1) Don't store passwords at all.   Rather, store only the password you need to access a user database for authentication, and not the password to the database containing the PHI.   The database password can be derived from the user's application password using a KDF, and it can be derived on authentication, rather than being stored.

2) Store the password, but encrypt the config file.  To prevent this from being simple obfuscation, you need to store the encryption key somewhere more secure than another config file, like in an HSM.

3) Ensure that indirect database access is blocked, in case of stolen credentials.  The database server should be firewalled and access should be via a whitelist.  In most cases, only the application (web) servers should be granted access to the database server.  This way, even if someone steals credentials, they can't simply log into the the database from their own machine.  Additionally, since the data by rule must be encrypted, if you decrypt using the application rather than database level functions, even if a malicious user does manage to access the database from outside of the application, they won't have access to unencrypted data.


Is there a particular security weakness from using server-side JavaScript? I never used JavaScript server side, actually I didn't even know that it would be used or useful there. Now that I found out that it is possible and there is a quite active community, I am wondering if there are some known drawbacks when used on the server side.

Are there some assumptions that I should be aware of on the sandbox model? Should I care about the same origin policy typically enforced by browsers or not?

JavaScript is a language just like any other language, such as C and Java. You can run Java on your desktop PC, and on your server as well. In the same vein, you can run JavaScript just fine on a server.

Node.js is one popular asynchronous I/O library that uses the JavaScript language. It runs extremely well in a server environment as evidenced by GitHub and Klout.

The same origin policy is only applicable in browsers, i.e. at the client side. The sandbox is still in the language in the sense that you probably will not hit a buffer overflow. It is not the same sandbox as implemented in browsers, that is, no access to sockets, and no access to files.

The bottomline is to think about JavaScript as a generic language.

The drawback from a programming point of view is the JavaScript interpreter runs single-threadedly. There could have been improvements in this area. From a security point of view there are likely no issues to worry about.


False acceptance rate in biometric authentication for sensitive information Every type of biometric authentication will have a false acceptance rate, which is the likelihood that the system will incorrectly accept an access attempt by an unauthorized user. Of course, when combining biometric with other authentication factors (e.g. passwords, or a security device), the chances of someone gaining access are significantly reduced.

However, when dealing with highly sensitive information (e.g. for access to banking, systems requiring PCI compliance, HIPAA compliance, etc), where even a single breach could imply a large risk, what would an acceptable false acceptance rate for biometric authentication be when combined with another authentication factor?

For example, if the FAR is 1%, and I combine that form of authentication with password authentication, would that be acceptable in this case? What about 0.1%? 0.001? I realize that this is relatively subjective, but I have no idea what a good range would be, so any actual data, studies or use cases would be appreciated, if possible.

Apple Touch ID has an FAR of 1/ 50,000  while Face ID has a FAR of 1 / 1,000,000

https://support.apple.com/en-us/HT208108

Android also insists on having an FAR of not higher than 0.002% (1 in 50,000). (Source: Android 7.0 Compatibility definition document)

A company called Eyeverify has a very relevant blog on this topic. They too seem to suggest that an FAR of 1 in 50,000 is good enough and they have clients in the banking sector.

https://www.eyeverify.com/blog/ceo-editorial-a-call-for-payment-grade-industry-standards


What server software uses .der? So apps linked against openssl uses PEM, and Windows generally uses PKCS12, but I haven't seem much .DER in the wild - what server software uses DER?

By default, OpenSSL files are created in Privacy Enhanced Mail (PEM) format. SSL files that are created in Windows operating environments are created in Distinguished Encoding Rules (DER) format.
Under Windows, you can import a file that is created in either PEM or DER format. However, a digital certificate that is created in DER format must be converted to PEM format before it can be included in a trust list under UNIX.

Here is an example of converting a server digital certificate from PEM input format to DER output format:

OpenSSL> x509 -inform PEM -outform DER -in server.pem -out server.der

Here is an example of converting a server digital certificate from DER input format to PEM output format :

OpenSSL> x509 -inform DER -outform PEM -in server.der -out server.pem


Designing a secure information system Could someone please provide me with some guidance for a system I am designing...

A general overview of the system is that it is to store information on staff and "customers" - this information must be completely secure as it is highly sensitive! Staff must be able to access this information remotely - with functionality to view, add, edit and delete records, and upload/download files.

So the three models I have thought of for this system are:

Remotely login to the server (I have seen an existing system doing this - would it be for    security reasons? and I assume it would still be running a client application on the server to allow multiple users?)
A Client application that runs on the users machine, establishes a TCP connection (would OpenSSH or a similar wrapper provide the level of security this system NEEDS?)
Building the system into the website - the browser effectively being the client (this is my favoured solution, however is it the best? )

Have I missed a better solution?

I understand all of these solutions could probably be built to be extremely secure, however I do not extensive knowledge of this area (but I am willing to learn)

Let's look at them in turn.

Remote Access.
Secure enough if you do it properly, usually not considered because it is the most expensive option and it really has no advantages over other options if you aren't doing anything fancy.

Native client with secure networking built in.
Secure enough if you do it properly, but it requires you to write security code, and you don't know what you are doing, so a bad idea.

Web client.
Secure enough if you do it properly, but it requires you to write security code, and you don't know what you are doing, so a bad idea.

Establish VPN link and run an insecure client.
This is one you left out. Secure enough if you do it properly, not terribly expensive, only slightly less convenient for users, sounds like a winner!

Note that although I have dismissed options 2 and 3, I have only done so based on the threat model you describe in your question, which may well be wrong - for example you are assuming the bad guys are all outside the network perimeter.


How far is my Access Point BSSID sent in my internet packets? My question relates to this question: How does Google know where I am? and ask a similar question to this (but that accepted answer doesn't pertain to BSSIDs).

The chosen answer in my first linked question describes a large database of previously saved geolocation information (GPS, cell towers) mapped to BSSIDs.

The reason for wanting to construct such a database must mean that BSSID can be retrieved at their (database maintainers, such as Google) end and then matched to their saved location. Is that correct? If that is correct, I wonder why BSSID would need to be sent beyond the Access Point?

Thanks

You access point is not sending your BSSID anywhere on the internet. It is just broadcasting the BSSID locally so that any WiFi devices nearby can see it (and connect to it if they want and have the credentials).

These WiFi devices might have a known location (for example determined using GPS) and thus can create a mapping between the known location and the visibility (and strength) of the BSSID around this location. These WiFi devices (and not the access point) then can upload this mapping to some central place where these information gets accumulated into a central database. Such central mapping then could be queried later to map visibility of specific BSSID's back to a location.


What kind of attack vectors are made possible as a result of Java being hopelessly intertwined with Android? "All the security of Linux … plus Java! “Java: The malware compatibility layer of choice” Android can be engineered for security, but when you’re done you have a hermetically sealed self contained comms device — not a smartphone"

Excerpt from COMSEC Beyond Encryption by TheGrugq

http://grugq.github.io/presentations/COMSEC%20beyond%20encryption.pdf

What does TheGrugq mean by this?

Android is essentially a huge Java virtual machine. There is the core operating system, the kernel running a virtualization system called Dalvik, and Dalvik runs a bunch of applications. Java is easy to exploit, many bugs have been discovered since Androids inception that allow breaking out of dalvik sandbox, you can google "Android dalvik CVEs" or "Android JVM CVEs" to see some examples. All the underlying security of linux is made less effective because of this. In 2010 security researchers were able to upload a malicious Angry birds game app to Android Marketpkace that invisibly downloads other apps without users permissions. Yes Android CAN be hardened for security, but not without compromising the user experieince.


Dynamically assign and revoke MySQL user privileges So I am following a course on Lynda.com about IT Security. They were talking on the Least Privileges Principle, how users or processes should have the minimum amount of privileges for the minimum amount of time and it got me thinking, would it be of any use to dynamically assign and revoke privileges to a MySQL user.

So as an example, lets say that on a Saas website, there are two MySQL users. One is 'admin'@'localhost' and the other is 'worker'@'xxx'. The Worker user will hold no privileges until it signals the admin that it needs to write to the database. After the worker user is done, it signals again to the admin user that its job is finished and the admin user revokes the writing privilege. Making the worker user useless in the case it got compromised.

This is generally a very good practice and often employed by large enterprises.

For example, have a look at the security applied to operational staff working on Microsoft Office 365 & Azure. They have NO access to data at all. When they need to trouble-shoot something and need access, they have to follow a process whereby they request the access from their ops security team along with the reasons and timescale. They are given access for a very limited time.

Of course, you need to balance this approach with the overheads of managing it. To be successful in any organisation, you would need to be able to automate the request/access process. That brings its own risks which you would offset using monitored audit logs.


How would you construct an XSRF attack using an iframe? I know that you can easily trigger a series of POST/GET to a target website using an iframe as I have done it in the past to manipulate session variable on my sites.

My question is more about : what information could I get from another website that I load into an iframe?

If I'm right, the same origin policy is supposed to block me from reading the iframe content if the page I load into the iframe is not from the same domain as the page containing the iframe. Is there any ways to do bypass that?

If there are information that I absolutely need to read on the page, like unique form submission token, how would you mount the attack?

The closest thing that matches your question is a Clickjacking attack (UI redress).

This is where you load another website within an IFrame that contains a button for the user to click. For example you (the attacker) could load the URL on a user's bank's website in the form https://www.example.com/money_transfer.aspx?to_account=12345&amount=1000000 where 12345 is your account number. If they are already logged into their bank and the response is a HTML form containing a single Transfer button, you could draw your own UI in your outer page that would replace the button with one that said Get a free iPad now!.

When the unsuspecting user clicks the free iPad button on your site, they are in fact clicking the Transfer button on their bank's website to transfer the money.

This sort of attack can be defeated by setting the X-Frame-Options HTTP header which modern browsers will obey and stop your website from being loaded within a frame.

Accessing the loaded IFrame using scripting is prohibited due to the Same Origin Policy - the only way round this if the user is using some old unsupported browser, or a browser containing a vulnerability where the origin is not properly checked.

The other possibility is a Rebinding Attack - the scope of this is usually limited as the cookies sent to the rebound IP will be the same as to the attacker's domain.


Why are SWAP partitions good for security? This page on server hardening has a large section on adding a SWAP partition.

Why is adding a SWAP partition good for server hardening?

It improves the availability of the system, which is also an important part of information security.

E.g. if there's a DoS attack on a memory intensive service, the box is less likely/takes longer to crash.


Lost password for encrypted external HD Have an old filevault encrypted external hard drive. Would like to access but have forgotten the password.

However I do remember the style of password (XKCD four word style) and remember two of the four words. So I can generate a list of the possible passwords. What I'd like to be able to do is use this list to brute force the HD, but I can't figure out how to do this.

How can I do that?

The answer to your question

If you know two of the four words and the position of said words, it should be an easy* task. Write a script that generates passwords depending on your source list and your two known passwords like $known_pw_1 $known_pw_2 $test_pw_1 $_test_pw2 (of course depending on the position of your known passwords). For each word you put in $test_pw_1 you need to iterate through all $test_pw_2.

There's also a good StackOverflow answer on how to input passwords into command line prompts.

*depending on the following The "BUT"

The "BUT"

So here's the BUT that will take all the fun out of your programming exercise above:

Depending on the word list you used and the alphabet (UPPER case, lower case or MiXeD?), you'll have a hard time calculating through all possible combinations. So if you're using the original diceware word list, it has 7.776 words in it. Meaning your initial password list with two variables has 7.776^2 (=60.466.176) possible combinations. If you have lower case and upper case words mixed, that expands to 7.776^4 (=3.656.158.400.000.000) combinations.

So if you calculate 1-3 passwords per second (I haven't checked the filevault specs but I highly anticipate that it will most certainly slow decryption down to prevent such brute force attacks) you're still looking at around 700 DAYS when calculating all 7.776^2 combinations, 4 BILLION YEARS if we're talking about 7.776^4. And we haven't even talked about mixed character words.

(my math might be off here, please somebody correct)

PS: Hashcat apparently does ~61.481 H/s


Fast data integrity protection I have a small device with a 16-bit (embedded) architecture, which transmits 1500 bytes every 3 milliseconds. This device has no built-in integrity protection, and it is possible to manipulate the data sent from this device. I was thinking of protecting the data integrity using HMAC or Blake2, but the problem is that these methods are slow for my application and due to the time constraint I cannot do a full pass over the data. I understand that I need to make a compromise between speed and security. I was thinking of the following two solutions:

1) to randomly select a smaller chunk of data and do integrity check; or

2) to use a fast checksum method.

I was wondering if there would be a better solution. I will appreciate your insights.

You could use the Fletcher16 algorithm and - not really very secure at all, but still - provide it with a "secret" IV, if feasible.

BLAKE2 boasts pretty good speeds, so if you can't use it I'm afraid MD5-class security is unattainable -- all comparable alternatives would be even slower.

Reordering the data so that sensitive information is gathered together and Blakeing that block might be feasible, perhaps.

Or you could prepare a block with a device secret and a copy of the few fields you want to protect, then send the packet together with the BLAKE2 hash of the check block, which would not be sent.

Relying on security through obscurity (needless to say, not recommended) you could append to the packet the N-bit XOR of the key fields; or a random N-bit value plus the XOR of the key fields and the random value, yielding an apparently random 2N-bit field.


Identifying the source of a Crypto Locker attack We believe a Crypto Locker virus may have found its way into our network. We're having trouble identifying which computer was responsible for originally bringing the virus in.

Does anybody have any experience identifying the source of a crypto locker virus on a network?

We had this in our network yesterday, after the network cable was unplugged from the back of the PC was when the crypto locker showed itself. So go around and unplug everyone's network cable and look at the desktop, you can't miss it.
Also, the only way to deal with this is to pay the demand ransom of $300. After we paid, it said "processing, could take up to 48 hours". Eventually it accepted the payment and decrypted the 1.5 million files in our network and now everything is back to normal.


Is it better for me to bang on the keyboard for 12 characters or use my password manager's generator? I use a password manager with a long rememberable master password for logging into all of my online accounts. When signing up for new accounts my password manager prompts me to generate a strong password which it then autofills. This auto generated password is a twelve character long alphanumeric string. Is there higher risk in me attempting to generate a random password by randomly pressing twelve characters on on the keyboard vs a potential flaw in the generator that would allow password discovery with some other available information (password creation time, password length, creation method)?

I know in the ideal case the password generator is far superior to my attempt to be random on the keyboard, but is my hand dropping on the keyboard so much worse that the risk of my password manager's generator being flawed is the better of the two options? I know this might be an opinionated question so any facts, studies, or personal knowledge on this topic would be highly appreciated. I did attempt to Google this question and my searches along the lines of "password generator vs random typing" yielded no good results.

PS: Where as I don't use them it might be cool if answers also addressed random typing vs going to Google, searching "password generator", clicking one of the top results, and then using a web based random password generator.

The password generator is better. It will use a system designed with the sole purpose of generating random chars. Your brain is not designed for this.

If you mash the keyboard a hundred times and create a heatmap of the typed keys, you will see the keys most used is the central ones, and the peripheral ones less so.

Open your text editor, and generate more than 30 passwords with your method. Then run this script:

awk -vFS="" '{for(i=1;i<=NF;i++)w[$i]++}END{for(i in w) print i,w[i]}' file-you-saved | sort -g -k2

It will take all the chars, count them, and sort them based on frequency. For your method to beat the password generator, the letters should have more or less the same frequency.

If the site you are logging in allows for more chars, do it. I use 64 when allowed, or the maximum allowed when it's less than that.


Certificate pinning and the key distribution problem I (think I) understand the concept of certificate pinning. However, I'm wondering if, in the worst-case scenario: is certificate pinning any more secure than the hierarchical trust model it is built upon? An example scenario:

I develop a mobile app, which uses secure connections
To encrypt these secure connections, I need a key
In the past, I'd just use HTTPS for the secure connections, and made sure my service had a valid certificate. I rely on others for my security.
Now, I don't want to rely on others anymore, so I start pinning my service certificate (let's say certificate X). This means that shifty CA's will not be able to break my security. Let's say I pin my public key, so effectively this means I don't trust any CA (otherwise I could pin a CA).
This brings me back to the original key distribution problem, that PKI was to solve: how do I distribute my application to my users? I don't want an attacker sitting in the middle of the channel and replacing my application with another one (and with another pinned certificate Y).
Well, that's easy: I use HTTPS.
...
I use HTTPS, which checks the certificates against the MS Windows store, which menas I have to rely on the shifty CA's from step 4.
Sidenote: everytime I send an update, an attacker (a shifty CA) might be prepared to intercept my update, and replace the pinned public key with another one.

The OWASP page mentions that the pin can be added during development or upon first encounter. However, when adding it during development, we still have to distribute the app to the users, which will pivot over the security issue to the distribution channel. This distribution channel might also pin certificates, but in the end, it all comes down to the trust of your first channel. In case of MS Windows, this is the MS certificate list: even though Chrome might check the pin of all Google domains, I first need to install Chrome over a secure connection.

I'm not saying certificate pinning is not any more secure (although I'm not sure about the added value, especially when considering point 9), I'm just wondering if the above reasoning is correct.

You mention mobile applications. Mobile applications are typically installed from a specific vendor-controlled app store (the App Store in the case of iOS devices and the Play Store in the case of Android devices). You have to trust the store to deliver the correct binary to the device but it's still much safer than the CA system that allows any CA to sign on behalf of anyone.

On desktop systems, this problem is much more difficult. Linux-like package managers mostly solve this problem through the use of package managers that verify packages signed with preloaded keys. Again, you trust the repository that delivers the package but it's a much smaller attack surface.


Is there any SQL injection for this PHP login example? I want to write a login form, and I got one example from the web.
I want to know, if there is any SQL injection for this code? If there is, what could the exploit's web form entry look like?

This is my form:

<form method="post" action="">

name:

<input type="text" name="username" id="username"  size="50">

pass:

<input type="password" name="password" id="password" size="50">

    <input type="hidden" name="post" value="1" />
    <input type="submit" name="submit" value="submit" class="button">
</form>

and this is my check:

if (($post[username]) AND ($post[password]))
    {
        $query = 'SELECT * FROM `config` WHERE `config_admin_username`="'.$post[username].'" AND `config_admin_password`=MD5("'.$post[password].'") LIMIT 1';
        $sql_user_check = $db->fetch($query);
        if (!$sql_user_check) {
            $error .= "Wrong Entry.
";
        } else {
            $_SESSION[admin] = 1;
            header("Location:index.php");
            exit;
        }
    }

I'm using phpmyadmin 3.2.0.1 on wamp 2.0i

You've come to the right place. Welcome to IT security!

  is there any sql injection for this code?

Yes

  if there is what is that Entry?

username: [any username from your website]" /*
password: sux0r")*/ OR ("1"="1

It will run this query:

SELECT * FROM `config`
WHERE `config_admin_username`="[any username from your website]" /*
      AND `config_admin_password`=MD5("sux0r")*/ OR ("1"="1") LIMIT 1'

If we remove the commented-out parts that SQL engine won't parse, this results in:

SELECT * FROM `config`
WHERE `config_admin_username`="[any username from your website]" OR ("1"="1") LIMIT 1'

SQL query will be parsed up till the commented out part (I used the /* and */ start-comment/end-comment pair in my example and assuming you're using MySQL, but that can be different depending on RDBMS used), effectively disabling your password check altogether. Even if in-SQL commenting is not supported, or disabled, the options to exploit your login are really limitless. I won't even go into your choice of MD5 as a password hashing algorithm, as you have a lot of other things to consider first. It clearly isn't the recommended hash algorithm for password hashing though.

You've done good to have come to this website and that you're asking yourself questions regarding your code safety. Congratulations, you're already a better PHP programmer than most that never got so far are! Now, it's up to you what you'll learn from already existing questions and answers here. Some tags to consider are php, authentication, web-application, hash,...


How are buffer-overflow exploits built to work against different targets? Let's say I found a vulnerability in some application and managed to exploit it on my machine. How do I make that exploit work against other machines when the stack layout and memory addresses are different?

Generally you have three options:

use the the stuff that stays the same (maybe main executable is not ASLRed, maybe some DLL isn‘t. Maybe some register always points to the same X)
find out where‘s what before you jump. you need some memory disclosure bug and a vuln you can exploit interactively, like over the network or from within the browser.
guess. This means either heap spraying or a vuln that you can attack over and over again until you succeed, like a web server.


The sent gmail was modified to other version, how to trace the record beside header? Recently, the emails I sent from gmail were either modified or the documents got replaced for others.

When i communicated with google, they only asked for the header but nothing else ..

Also, when i see the devices in recent activities, I see a WINDOWS PHONE which is not my device, but google has only advised me to change the password.

But this has happened many times already.

What should i do?

the emails I sent from gmail were either modified or the documents got
  replaced for others

Where do you see the modification? In general, email does not guarantee the integrity of the messages, you need to digitally sign them to have this feature.

If you see the modifications on your Google account then someone has signed in with your credentials or used your device.

If you see the modification at the receiving end than either the receiveing end has modified the content or someone on the way (not likely).

  Also, when i see the devices in recent activities, I see a WINDOWS
  PHONE which is not my device, but google has only advised me to change
  the password.

Changing the password is not enough if the new password leaks somehow (for instance via a keylogger or someone spying at you). You need to enable multifactor authentication. In that scenario, someone having your login and password will not be able to log in from a new device - they will be required to also provide a number which changes every minute.


Determining false positives when scanning for live hosts with Nmap When doing a vulnerability assessment on a large network, it seems general practice to determine which hosts on the network are live.

This can be done in various ways. From what I have read it is good to do some ICMP scans, perhaps use a vulnerability scanner that has a discovery component, and perhaps do some TCP/UDP scans to find hosts that don't respond to or block ICMP traffic.

I've run into a problem when doing TCP or UDP scans to determine if a host is alive or not.

Consider a sample network of 1000 hosts. Perhaps 50 will respond to ICMP traffic and can be considered live. Sometimes when doing a TCP/UDP scan, every host will be considered by nmap to be live, even if no ports are detected.

This is by using the -PN switch with nmap, which is necessary as otherwise hosts appear to be down and I do find additional live hosts with tcp ports open this way. It's just that most other hosts are also reported as being live when this isn't the case.

Is there a way to weed out false positive (i.e. hosts that report as up but have no ports open) for live hosts when using TCP or UDP scans?

you can use the flag -PE, which performs a ICMP echo
as an example:

  nmap -sn -n -PE 192.168.1.1-255

or for a cleaner result

  nmap -sn -n -PE 192.168.1.1-255 | grep report | cut -d" " -f5


Do large online software companies limit employee access to company information? I've been wondering about how large online software companies, specifically those based around a single massive product, like Google, Facebook, Yahoo, etc. handle the risk of terminated employees. Any employee with sufficient knowledge of internal security could potentially use this knowledge for vengeance against the company.

Obviously, any company that can't trust its employees has far deeper problems than simple security worries, but after running through scenarios it would seem that Google, Facebook, Yahoo, would have to limit what their employees know to what they need to know. An employee writing protocols to send data between servers obviously needs some dangerous information to do his job, but he doesn't need to know about the outer security. An employee working on anomaly detection is clearly involved in security, but doesn't need to know about how requests that make it through are processed. In other words, it would seem these companies adopt the same principles with their employees that they adopt with their code: principle of least privilege and no potential single point of failure.

Does Google, for example, restrict what their employees know to what they need to know? Is this industry standard?

The basic rules that the big companies follow aren't very much different from the rules/recommendations by popular infosec standards (e.g. ISO27k):

Segregation of duties - separation on services provisioning, development process, or any other part of IT services, so different people are responsible for the various components/stages of service delivery, development, provisioning, etc.

For example - one team is responsible for hosting/systems provisioning, another team is responsible for product development, a third team is responsible for storage/databases, etc.

Overall, no single person has access in a way that may lead to the whole process being compromised. However, this measure alone is not sufficient for obvious reasons (didn't help in the case of Ed Snowden).

Least privilege principle - as you already mentioned, any employee is provided with the minimum credentials necessary for them performing their duties.

This is another measure that on its own won't help completely eliminating the risk of ex-employees or current employees from compromising the integrity, confidentiality, or availability of the information (again, didn't help in the case of Ed Snowden).

Have good asset management program - know who has access to what. Having a current and clear picture of who has access to what can help in the next stage.
Account lifecycle - have processes in place that run when employees leave, ensuring their credentials are revoked.
Encrypt! And have a solid key management process.
Look after the intellectual property (IP) - as much as software patents are debatable, and lawyers aren't the people I'd like to rely on, having the company's IP secured definitely helps (patented, registered or otherwise copyrighted).
Background checks. Small businesses can't usually afford proper background checks, but the big ones definitely do their homework in this department.
Run a data leak prevention program (a mix of solutions, procedures and monitoring).

These are just some of the basics that would limit any potential risk of damage that an employee (or ex-employee) can cause by using their insider knowledge. You can't erase what employees know (e.g. system architecture, protocols, etc), however the folks that typically have access to the keys of the castle are not just starting their careers, so any potential traits that would make them less-than-trustworthy would show up during some of their previous employment cycles, or during their probation.

No organization can eliminate the risk completely, but following common sense approach, combined with strict adherence to infosec standards can save you a lot of trouble in the long run.

With regards to specific measures within large corporations, each one is a bit different, since there are substantial differences in their culture, in their governance and their general risk apetite. There's no silver bullet, and they still need a good incident management process to respond to whatever they have missed :-)


How is user authentication sent in a public wifi? Radius/802.1x/EAP etc I visit the airport, I pull out my laptop and connect to a network (no password needed).

I open up my browser and i am presented with a screen saying I need to pay to use the network. If I pay, I presume if I close my browser and then open it back up, it wouldnt ask me to pay twice.

How does the browser know when the user is authenticated?

I know this answer includes 802.1x, EAP and RADIUS protocols but I cannot see how and what the client transmits when all they are doing is opening up a normal web browser?

Everything is authenticated based upon the mac address of your wireless card.  When you connect initially you are assigned a DHCP address by the gateway device which is controlling your DNS.  Before you are authenticated all DNS requests are redirected to the HTTP(S) server of the gateway device. This controller has created you an account based upon your mac address and once the payment authorization is received it enables your account to access the public DNS server for full access to the internet.


How secure is it to use an open-source software Is it possible for the developer of an open-source software to hide a backdoor without getting caught?

Obviously open-source is superior to close-source when it comes to transparency, also I am aware of the fact that open-source does not necessarily means 0-day-free (if there is such software) but has it ever happened to discover a backdoor in an open-source software?

Backdoors in open-source software where discovered, yes.

Generally speaking open-source does not automatically mean the software is secure or free of bugs. Just remember Heartbleed in OpenSSL.

One of the main problems is that everyone could take a look on the source but often no one actually does thinking someone else surely did it before. So it is possible that there are bugs or backdoors for a very long time hidden in some project.

Another Problem may be the complexity of some projects, it is just not possible for a single person to look at the source and know it is safe or not - you would need a long time to accomplish this just see the security audit of TrueCrypt for example.

In this context a main problem of open-source is that everyone can modify the code and share his own programm. There are many cases of this, manipulated versions of big open-source programms like Firefox, PhpMyAdmin etc. The normal PC-user won't ever notice that there is something wrong but he is happily using a big backdoor.

So open source may be a little bit more secure because in theory everyone could check the code but in practice bugs or backdoors may be undiscovered for a long time. And please don't get me wrong, I'm a big fan of open-source software but I am aware of the risks and so should anybody else.


Is there any real security benefit to forced password change intervals? This question is quite basic, but it bugs me and I'm sure it bugs a lot of other people as well.

What is the real security benefit to forcing users to change their password say every 60 days or every 90 days?

Benefits

Compromised credentials are useless after a short period of time.

Drawbacks

User resorts to easily remembered password increment schemes—password1, password2, passwordN.
User is forced to expose passwords on other mediums to recall them—post-it note, other devices, etc.
User has to reference exposed passwords increasing vectors for attack, as compared to a recalled-from-memory password.

It seems there are more drawbacks than benefits, so why is this security practice so prevalent?

Update from FTC article which shares some of my concerns:

  The Carleton researchers also point out that an attacker who already
  knows a user’s password is unlikely to be thwarted by a password
  change. As the UNC researchers demonstrated, once an attacker knows a
  password, they are often able to guess the user’s next password fairly
  easily. In addition, an attacker who has gained access to a user’s
  account once may be able to install a key logger or other malware that
  will allow them to continue to access the system, even if the user
  changes their password.

Similarly, they share the same hypothesis.

  While we don’t yet have a controlled study demonstrating the impact of password expiration policies on user behavior, there is quite a bit of evidence to suggest that these policies may be counterproductive.

Link: Time to rethink mandatory password changes

Supposing that the hashing function was correctly selected, it should take more than 60 days to crack a password that follows correctly selected password policies.

Therefore, if a malicious actor has permanent read access to your credentials database, since they would only have access to hashes, and since the hashes would change before a password would be cracked, the passwords would still be safe.


Does Java/Dalvik's Java Native Interface JNI make Android prone to better attacks? Java has a feature named Java Native Interface (JNI), which allows to call native machine code function from inside the Java's bytecode. This feature allows effectively running machine native code from a native shared library, which -in the case of Android apk apps- the app developer provides inside the apk package.

My doubt is if this JNI should this be a security concern? I.e. that code outside of Dalvik virtual machine, direct native code could be imho a higher risk to attack the system, as it the java bytecode through Dalvik?

Is native code a bigger security concern than code in a virtual machine?

Some Background

JNI is not the only way to run native code, albeit a conveniend one because one does not have to do lots of copying/embedding of a binary to run (i.e. from the apks assets to a executable location) Anyway also this is possible:

 Runtime.getRuntime().exec("/data/data/my.package/my.code.bin").

Now I am aware that, nothing is yet ultimately lost, only because native code is executed, e.g. the security model of many desktop boxes also works with native applications running. Indeed one is at least lucky that Android stuffs apps into their own user id UID, so one might at first hand say, that even natively one is safer on Android, than running firefox and chromium with the same me@mybox user on some desktop boxes.

The curcial point, which also motivates the question if it constitutes a security concern, is that native code appear to me much more flexible to attack the system via systemcalls and buffer overruns etc, than possible for an attack occuring from within the apk/apps Java codebase. After all even for legitimate stuff Dalvik/Java gets much in the way and is disabled because of its portability goal.

Assuming there is a risk associated with JNI and the exec call, am I mistaking or does Android lack a permission setting for that. So in attition to evaluation the question, there should be "extra upvotes" for confirming or refuting that Android does not have as-per-app permission settings for JNI. My poc app at least installs with the message:

  Do you want to install this application? It does not require any
  special access?

which seems to indicate to me that it would not require any permission at all. Yet I know it can run native code and JNI native code.

Yes, absolutely.
In fact this answer is kinda trivial, in that native would obviously be vulnerable to additional classes of attack, such as buffer overflow - just as you note in your question.

There is a very specific CWE (111) that applies here:

  When a Java application uses the Java Native Interface (JNI) to call code written in another programming language, it can expose the application to weaknesses in that code, even if those weaknesses cannot occur in Java.

Now, the interesting thing here is actually the Android sandbox.
While the vulnerabilities mentioned are in fact relevant here, and do make the native code higher risk, that does not necessarily enable a library to break out and escape the privilege sandbox. As you say, Android apps run with their own UID and limited privileges, per process.
In fact I find this highly unlikely, though not impossible - if you do find it, that would be a nice disclosure, and hopefully it would be fixed in short order.


Security code review Apple Swift - tools and documentation I need to perform a security code review on a huge Swift application. I have done many mobile penetration tests before and some code review but never on iOS Swift Apps. I am primarily looking for information and reference material which will help me answer the two questions:

Could you provide information on how to conduct a source code reviews of Swift and Swift code for security flaws.
What would be a good approach for automating the source code review using either static or dymanic analysis of the source code?

I encourage you try out https://www.kiuwan.com
It has out of the box custom rules for Swift, it allows for custom rule creation and has scored the highest benchmark on Owasp for SAST vendors.
Disclaimer: I work there


Over-the-top (?) security practices for CVV inputs On some internet banking websites, I've seen some CVV input fields that seem strange to me. Here is an example:

The field works as such:

You can not input a CVV code using a keyboard.
The numbers are never in their normal order (1, 2, 3...).
The positions of the numbers are shuffled each time you open the CVV input panel.

So my question is:
Is there a point in making the numbers shuffled each time you want to input a CVV code?
I understand that you might want to disable the keyboard input and use a mouse instead to defend from keyloggers, but is there any point in making the positions of the numbers shuffled?
I do also understand that this approach is a good idea on a touch display as it removes the posibility of guessing the pin by the fingerprints on the display, but the cursor does not leave any fingerprints behind.
And if this is made to defend from keylogers that also log your mouse clicks, is it actually effective, knowing that if the keylogger logs your mouse clicks, there is no reason it can not also make screenshots?

All your suspicions are correct:

it is meant to defeat keyloggers
it is meant to defeat touchscreen fingerprints
it is meant to defeat mouse loggers (you can derive the number sequence from the relative position of the mouse when it clicks)
it will fail against loggers that take a screenshot when the mouse is clicked

Is it actually effective? Well, it depends on what the threat actually is. It is effective against the threats that it is effective against and weak against the threats it is not designed to defend against.
Which threat is more likely? That's not always easy to guess. I'm not sure that any are likely at all. Those are not the types of threats that are dominating right now.
But what this does do is to make it look like the site is "really secure" for implementing such an extreme measure.


Does Ephemeral Diffie-Hellman require a certificate? In Ephemeral Diffie-Hellman, the key pair is generated every time.

In practice, does this mean I never need a certificate? Or that means I need a new cert every single time?

You do need a certificate, because the Diffie-Hellman parameters have to be signed. Diffie-Hellman only makes sense if the client can rely on the authenticity of the parameters (meaning: they actually come from the server). Otherwise a man-in-the-middle attack would be trivial.

You just need a standard RSA (or DSA) certificate. In fact, the only difference between DHE-based cipher suites and “classical” RSA suites is how the certificate is used: With DHE, the certificate is only used for signatures, not for encryption.


Does replacing a bcrypt hash with an invalid hash result in no possible working password? I have a manager who likes to "deactivate" accounts by replacing the existing bcrypt hash in the database with a simple dash (-).

This seems to work as the old password is no longer valid and there is no valid bcrypt hash that any other password could match. But I was curious, is this effective or does it create a security risk?

Is this an effective way to make no password work or does it create a larger security risk?

This specific implementation uses the PHP password_verify function but I would like answers to focus on any general implementation. Please do not focus on my manager's bad practice. We also have a boolean field for setting the user to inactive/active which I believe is better and safer but is not what I want answers to focus on.

In terms of disallowing legitimate login attempts, it's fine. Unless you're using a very weird hash function, there won't be any values which map to -, and it prevents brute force attacks against the missing values if the database is stolen too, which is a positive (they were unlikely, given the use of bcrypt, but this applies even if the implementation is using a terrible method for storing passwords - pretty much anything other than plain text).

In terms of downsides, if the database is taken, it slightly decreases the security of other accounts - the attacker has fewer records to brute force. If they are paying attention, they should probably remove the records which are marked as inactive, but still. I did say "slightly"...

The other risks could be if there are any methods for access which allow bypassing the hash method for comparison (e.g. you have a legacy method which allows supplying the full hash for some reason) - in that case, if you aren't checking the active status carefully, it might allow access by supplying a dash. Ideally, remove this access method, if this is the case.


What are the (practical) dangers of writing your own login method? I have always been told that writing your own login method (e.g. validate user given the username and password) is bad practice, and that one should reuse existing libraries for that.
I have always believed that, but I am looking for practical threats in such a scenario (C#). The practical case I am looking into is customizing a login method to include the validation of a Captcha. I haven't found any existing library to do that inside the authentication logic.

One of the implications of my custom implementation is that the validation method does not return a bool, but another type. May this pose a danger?

The danger is expressed in Schneier's law:

  any person can invent a security system so clever that he or she can't imagine a way of breaking it.

The only way anyone knows to test if any given system is secure is to have lots and lots of clever people try to break it over a long period of time. You won't have that with a system you rolled yourself.


When is Veracrypt an acceptable solution? To manage security risks effectively, a non-profit organization has the following high level requirements;

Limit access to authorized staff.
Sensitive data is only accessible to authorized staff.
Data integrity must be maintained.
Access to data must be auditable.

As a number of staff work off-site, it's important that data is stored securely both on the device in use as well as media such as DVDs and USB sticks/drives.

Historically the devices have used TrueCrypt full disk encryption. As the devices are being retired and refreshed (donations), there is an opportunity to inform the choice and solution to protect the devices.

The staff will be transitioned to Microsoft Windows 10 and OpenSUSE. Deployment of Windows 10 devices is limited due to budgetary considerations. Not all devices support TPM. There are approximately 50 devices of which the majority are non-Windows. Additionally, the editions of Microsoft Windows will be either Home or Professional.

In addition to Veracrypt, there is the option to use Microsoft Bitlocker and LUKS. In researching online, (Full disk options for example), there doesn't appear to be a clear view of the use cases in which the options are best suited for.

For example;

Should Veracrypt be limited to encrypting removable media?
When should LUKS be considered?

You should use LUKS2 with authenticated encryption.
You can format a device for this by running:

cryptsetup luksFormat --type luks2 $dev --cipher chacha20-random --integrity poly1305

You specified that data integrity is a requirement. In that case, you should not go with VeraCrypt, as it does not provide full integrity. It uses a mode of operation called XTS which is not great on its own. It is also malleable, which means someone can modify the plaintext by modifying the ciphertext without knowing the key. However, they are limited to only randomizing 16-byte chunks of data. That is, modifying a single bit in the ciphertext results in 16 bytes of plaintext being randomized without VeraCrypt noticing. When you use LUKS2 with authenticated encryption, this issue is mitigated and integrity is protected.

Now, does VeraCrypt have any use-cases that LUKS does not? Sure. VeraCrypt is easier to get working under Windows than LUKS, but the biggest benefit is plausible deniability. If you are in a situation where you have an external encrypted drive and someone is demanding that you disclose the password, you can claim that the drive was wiped and does not contain encrypted data if you use VeraCrypt. If you use LUKS, this will not be possible as it contains a header specifying that it is LUKS. VeraCrypt also has the additional benefit of supporting hidden volumes, which can be useful in certain repressive regimes.

Note that plausible deniability and hidden volumes may not work effectively on solid state media.


Bypass login with mqsql_fetch_object - Sql injection I have the following PHP Code and I am not able to pass the authentication using a SQL Injection. Do you have any ideas how to do it?

$password=md5($_REQUEST['dr']);
$result=mysql_query("SELECT dr FROM table WHERE user='".$username."'");
if (mysql_fetch_object($result)->dr==$password) {
            $okay=true;
}

There is a SQL Injection obviously on $username parameter, but you can't bypass login, because the password is compared with the result of the query, for example, if you inject ' or 1=1 --, the query will be:

SELECT dr FROM table WHERE user='' or 1=1 --

But this doesn't mean you can access to the application, the following line code shows how the result of the query is compared with the parameter dr:

if (mysql_fetch_object($result)->dr==$password) {
            $okay=true;
}

This is part of the best prractices about login based on SQL queries; compare username and password independently.

I hope this information helps you.


Where should the authorization logic go in an api based application? I have a brand new Rails api based application, where i need to implement authorization.

Overall Architecture:

React frontend -> Rails API layer -> Rails model/server layer

While exploring different approaches, I have got a confusion.

Should we put the authorization logic in API layer or Service layer?
API Layer Approach:   We will build some authorization middleware that will sit between our front end and API layer and all our api calls will be routed thorough the authorization middleware to check if the user is allowed to call that parituclar api.
Service Layer: All the authorization check will go to service layer and we will have check before every db operation if the user is allowed to do so. (Using cancancan / pundit) and if the user is not allowed throw the error message to API layer.

It would be a great help, if someone could suggest based on their experience.

Obviously authorization needs to be checked on the server side, as relying solely on client checks opens you up to malicious clients. There's no general consensus on where in the server-side code you should do these checks, but I'm going to argue for it being as close to the edge as possible.

For one, this is often the easiest. You have immediate access to the data of the call, and can return the appropriate error message directly instead of relying on an exception bubbling up through several layers.

Secondly, authorization is often more complex than you might anticipate. Take GitHub for example - to perform certain sensitive actions, you most first re-enter your password. This sort of check tends to be much easier to deal with on a page-by-page basis, rather than building complex conditionals into the model layer.

From a security perspective, there's definitely an argument to be made for a deep authorization approach, namely that you don't rely on developers remembering to handle authorization in every new endpoint. However, my opinion is that the clarity and simplicity gained from an edge-based approach outweigh these benefits.


How can I check a .srt and .txt file for malware? I recently downloaded subtitles for an episode of a series. I then looked at whether .srt files could contain a virus and found that that was indeed the case with some .srt files which exploited a vulnerability in a media player when loaded.

That info I found in an article from a year or 2 ago, so I wondered if this was still the case (especially for the default Android video player, I was planning to use the subs when watching the movie on my phone).

Another thing that bothered me was the fact that to check the contents of the .srt I used the website https://subtitletools.com/convert-subtitles-to-plain-text-online and downloaded a .txt of the .srt from there. I then disabled hidden extensions and opened the .txt with notepad, which sure enough revealed normal text.

Later, I saw the option to open the .srt file with Notepad++, but stupidly enough already downloaded the .txt from the website above.

That's why I am wondering whether there is a possibility of malware being present, in either the .srt or .txt (or both).

Both .srt and .txt subtitles and like other well known formats are pure test files - they contain text with time indexes and that's it.

It is highly unlikely that a random malware can spread by itself even if inserted in such files.

However, the only thing you should worry about are special vulnerabilities which could in theory specifically crafted so that a specific player's subtitle interpreter ends up doing something unwanted. There are over 25 subtitle formats in use, each with unique features and capabilities, which could be exploited against a specific player.

Here's an example: The StripTags function in the USF decoder and the Text decoder in VideoLAN VLC Media Player 1.1 before 1.1.6-rc allows remote attackers to execute arbitrary code via a subtitle with an opening "<" without a closing ">" in an MKV file, which triggers heap memory corruption.

Here's a take-over example video.

So, to make sure everything is fine, the 1st step is to make sure that your anti-virus solution does scan such files and does not ignore them (considering them text only and not scanning them).

Then, the next step is to patch the media players you use.


Is it possible make brute-force attacks ineffective by giving false positive answers to failed log-in attempts? I don't have any experience or scientific knowledge in security, I just wanted to ask if this is possible because I am interested in it.

What if I encrypt data and every password decrypts it, but only the right one does not create pointless data clutter?
Same could be done with a login: false login data leads to fake, dummy accounts and only the right login details get you to the right accounts.

Wouldn't this be a way better method of encryption because you couldn't just try out passwords but had to look at the outcome to see if it was the right one?

The answer always depends on your threat model.  Security is always woven into a balance between security and usability.  Your approach inconveniences the hackers trying to break into the account, but also inconveniences a user who merely mistypes their password.  If the fake account is believable enough to fool an attacker, it may also be believable enough to fool a valid user.  That could be very bad.

This may be desirable in extremely high risk environments.  If you had to store nuclear secrets out in the open on the internet, having every failed password lead you to an account that has access to fake documents which don't actually reveal national secrets could be quite powerful.  However, for most cases it is unnecessary.

You also have to consider the alternatives.  A very popular approach is to lock the account out after N attempts, which basically stops all brute force attempts cold, and has usability behaviors that most users are willing to accept.


Isn't Autohotkey effectively a keyspectator should I feel safe that I'm allowing this program to watch my keystrokes Recently I started using Autohotkey just to automate some abbreviations so it's a hotstring e.g

::btw::by the way

  Replaces "btw" with "by the way" as soon as you press an default
  ending character.

Effectively it's watching my keystrokes and (not logging them) but then I feel that makes me insecure? But I really want to use the tool. I can't tell if I'm being pedantic or my points are valid but essentially I see it as a potential keylogger since it does watch the keystrokes it just doesn't store them maliciously.

Is it still safe to use, keystokes are quite sensitive including passwords, credit card data etc so should I feel okay using this?

Especially because I may use this at work at some point. (Won't be entering credit card data at work but will be using passwords ofc).

You don't have to trust it any more than you trust any other program you run. Any program could steal everything you type if it were malicious; the fact that AutoHotkey reads what you type as part of its legitimate function doesn't make it any less safe.

Further, AutoHotkey is trusted and known to not be malicious. (It's also open-source, so if you don't trust other people to vet it, you can do so yourself and then build from the source you verified.)


Is there a more precise approach to generate signatures for ClamAV, than regex signatures? Actually I generate signatures from libraries, to scan executables for beeing statically linked to that library. My actual approach is to read out the .text section and generate a byte sequence for every function with placeholders.

For little version steps of the library there are many false positives with the clamscan from ClamAV.

Is there a better approach, to generate signatures for libraries and detect with ClamAV afterwards?

It seems that ClamAV supports both YARA  and OpenIOC. These two methods of writing signatures will let you take a much more specific look rather than just byte sequences. Check out this SANS paper for a bit of methodology.

If you want just a quick idea of what these two frameworks can hone in on check out the documentation for YARA and IOC. Both of these frameworks have a lot more documentation on how to write good signatures that will be good further reading material.


How different should passwords be? It seems to be generally accepted the same password should not be used for different sites or devices. How different should passwords be? For example +_^gum<JW1 and +_^gum<JW2 are very similar. Does it matter what the passwords are used for, for example having two e-mail accounts with similar passwords may be poor security but would having an e-mail account and encrypted USB device with similar passwords be better? What if two or more passwords follow a pattern or relation? For example applesorangesbannansand pottatoescarrotsturnips

I have read that all passwords should be random. This is ideal but not feasible.

It is most difficult to remember and password managers may not be a viable option (for example password to memory stick you carry with you).
It has been stated that computers should not be used to create random passwords.
Some devices it's very hard to type long complex passwords in, such as smartphones.

I have red that all passwords should be random. This is ideal but not feasible.

Why not?

  1)It is most difficult to remember and password managers may not be a viable option (for example password to memory stick you carry with you).

Why isn't it feasible? I do it all the time.

  2)It has been stated that computers should not be used to create random passwords.

Where is this stated? This is blatantly false.

  3)Some devices it's very hard to type long complex passwords in, such as smartphones.

Smartphones have password manager apps as well. They allow you to copy and paste passwords stored in them.


Mix and match RSA and ECDSA in TLS Suppose TLS client and server want to communicate, authenticating both parties. They each have sufficiently trusted certificates, but one corresponds to an  ECDSA private key and the other corresponds to a RSA private key, or maybe ECDSA private key with a different curve (not sure if this makes any difference). I am not specifying the algorithms used to sign those certificates, but please say if this is relevant. Would these parties be able to communicate - either at all, or, specifically, with the client being a mainstream modern browser?

YES -- there is no necessary connection between the types of keys and certs used by TLS server and client for authentication (nor between the Certificate Authorities and trust decisions).

For TLS versions through 1.2 (and SSLv3, which no one should be using now), the server key-and-cert must match the key exchange portion of the ciphersuite used, which the server selects from among those offered by the client. See the table beginning about a page into rfc5246 section 7.4.2 and similar in earlier versions. In practice this is implemented the other direction: when choosing the ciphersuite the server will only consider those offered by the client and for which it has a suitable key-and-cert. (In cases where the server is mistakenly configured with no key-and-cert(s), which is fairly easy in Java where usually you configure only a keystore file and people who don't follow correct instructions can easily create a keystore file that doesn't actually contain a key-and-cert, this causes the server to reject all connections with an exception or error saying 'no cipher overlap', which some people find confusing and ask about on Stack.)

For ECDSA cert, the client may (and most do) specify the curves it implements using extension 10 defined in rfc4492 section 5.1.1 and modified by 7027 for Brainpool as linked by the ietf website at the top, in which case the server is only permitted to use a cert (and if applicable chain) using the specified curve(s), and thus in practice will select a ciphersuite requiring an ECDSA cert only if its ECDSA cert (chain) uses such (a) curve(s). The client similarly can constrain point formats used in the server cert(s) using extension 11, but in practice this is usually not an issue.

In TLS1.2 only, for both RSA and ECDSA (and DSA as well) the client can specify signature_algorithms extension 13 defined in rfc5246 section 7.4.1.4.1 which constrains both the public-key algorithm(s) RSA,ECDSA,DSA and the hash(es) used by the server cert chain; see the text at the end of 7.4.2 in rfc5246 only (not earlier versions). Before 1.2 there was no explicit constraint on CA/chain certs above the server cert (except for the rarely used static DH_{RSA,DSS} and ECDH_{RSA,ECDSA} keyexchanges), but it was a fairly common convention to be homogenous, i.e. a server RSA cert would be issued by an RSA CA and a server ECDSA cert would be issued by an ECDSA CA (either the same curve or a stronger one, in practice almost always the two curves then in NSA's Suite B, P-256 and P-384).

For TLS 1.3, keyexchange and server cert is no longer tied to ciphersuite. Instead client always specifies signature_algorithms extension 13 (but using mostly different values than 1.0-1.2) and may also specify signature_algorithms_cert extension 50 as described in rfc8446 section 4.2.3. The supported curves are now limited to the three FIPS-186 prime curves (P-256, P-384, P-521) and the two Bernstein curves (ed25519, ed448) -- which were pretty much the only ones anybody used anyway -- and there is no option for point format; the originally-X9 curves must use uncompressed and the Bernstein curves use the only format defined for them.

Lastly, for some application protocols using TLS notably including HTTPS and thus web browsers, the server cert must match the hostname expected by the client. This is usually a fully-qualified domain name (FQDN), and since the TLS connection is made at the IP-address level, the ClientHello may contain a server_name extension (defined in rfc3546 for 1.0, rfc4366 for 1.1, rfc6066 for 1.2 and 1.3) to guide the server in choosing the key-and-cert to use.

The client cert on the other hand is controlled mostly by the CertificateRequest message sent by the server. In all protocols if the server doesn't send CertificateRequest the client does not authenticate at all. In 1.0 and 1.1 (and SSLv3) CertificateRequest specifies only the supported (acceptable) public-key algorithms, which need not be the same as the one(s) for the server's own key-and-cert (chain), and possibly a list of Certificate Authorities (CAs) that the server prefers the client use, which again need not be the same as used by the server's cert chain. In 1.2, the server also specifies a signature_algorithms field which constrains the client cert chain in the same way the extension in ClientHello constrains the server cert chain. For ECDSA in 1.0 through 1.2, there is no constraint on curve, apparently on the theory that servers are never constrained e.g. embedded/IoT(!), but the server may constrain point formats using extension 11 in ServerHello (before CertificateRequest) which AFAICS provides no benefit. In 1.3, the server must specify signature_algorithms and may specify signature_algorithms_cert, as well as certificate_authorities (now an optional extension instead of a possibly empty field); see rfc8446 section 4.3.2 including the text about 'prior versions'.


Checking if Mod_Rewrite is Enabled Remotely When pentesting it is useful to know when apache mod_rewrite is enabled. But when one comes across a web server that does not utilize PHP it is difficult to tell if mod_rewrite is enabled considering that URL redirection isn't very necessary. Is there any way to tell if it is enabled (remotely) without simply guessing common URL redirections?

You might be able to test for poorly configured mod_rewrite configurations.

Metasploit Proxy Bypass Scanner
Metasploit LDAP BO
w3af has a bug that doesn't handle mod-rewrite properly, so you can end up leveraging the bug to fuzz a site to determine if it has mod_rewrite enabled

Of course, these are probes that only work if mod_rewrite exists and is unpatched and configured in a certain way.

Otherwise, I'm not sure if one could detect what is supposed to be transparent...


SHA-1 how and when is it really a problem First, here’s my interpretation of the certificate validation process (if mistaken, please feel more than free to correct me).

When connecting to a web site using https, the website present an SSL certificate to the browser. It is used to authenticate the website. The browser has to have a way to decide whether to trust that certificate. The browser does this by checking whether the website’s certificate was issued and signed by a trusted Certificate Authority.  When a certificate is issued, the Certificate Authority includes this proof by cryptographically "signing" the certificate using a private key, in a way only the real CA could do and that browsers can verify. But the CA doesn't actually sign the raw certificate. If runs the certificate through a one-way-hash algorithm like SHA-1 and signs it with the CA’s private key. When the browser is presented with the certificate one of the first things it does is to check the signature. Because the certificate was signed with the CA’s private key (and we assume that it is only in the CA’s possession) we can verify the signature (thus authenticate) the server because the CA’s corresponding public key is wrapped in a X.509 certificate that is pre-loaded in the browser. Next the browser calculates the SHA-1 for that certificate and then compares with the value presented in the certificate sent by the website to check it’s integrity, that it was not altered in transit.

If the above is true, then I have the following question. Although it was recently proved by researchers at Google that two different .pdf files produced the same SHA-1 value, thus a collision occurred, I’m wondering how this can be exploited. I mean, say example.com got a certificate with a SHA-1 value equals  X and it’s signed by Verisign. An attacker creates an certificate for example.com and the SHA-1 value also equals X, so again, we have a collision, but this time it is not by any trustworthy CA! So if the attacker now tries to impersonate example.com, how this can be exploited if the browser will not be able to verify that it was signed by a trusted Root CA? Wouldn’t this cause any issues only IF the Root CA gets compromised ?

Added:
Or why it is even a problem with document signing ? I mean, say a business partner is about to send me a contract. It's signed by him and I can verify and I sent it back after signing with my private key. So, why should I be concerned that he was able to compute a similar looking document with the same hash value ? If I didn't get it, how he can prove that I signed it? I guess, he can't. And even if I get the "fake" document, just because it is signed, shouldn't I still verify what's in the document before signing and sending it back ?

EDIT:

I think I start to understand. So, if for certificate A, the message digest equals to X and a Root CA signs it with its private key everyone can verify its authenticity by decrypting the signature with the public key that is pre-loaded in to the browser in form of a X.509 certificate, correct ? So given the hash value of X (as it is not a secret anyway) and even not knowing the private key that signed the hash I know that the final result (signature) = Y. So if I know that certificate A’s hash = X and I’m able to compute another certificate (with the Issuer filed set to the Root CA that signed the real certificate) and it’s hash value will as well = X (collision occurred), even not knowing the signers private key, if I supply the Y value as for the signature (because the unique hash of the certificate plus the encryption through the private key would produce a signature value of Y) , the browser will accept and validate the certificate, because it will be able to decrypt the signature with the corresponding public key of the Root CA, that is performing the validation, compute that hash again and match it against what was send by fake server and the fake certificate, correct?
Thank you

An attacker creates an certificate for example.com and the SHA-1 value also equals X, so again, we have a collision, but this time it is not by any trustworthy CA!

The CA for a certificate is specified by the issuer field inside the certificate. The certificate is verified by looking for a trusted certificate which has this issuer as a subject and then use this certificate to validate the signature.

This means that if an attacker has a valid certificate which was signed with SHA-1 by a trusted CA and wants to use this signature for its own fake certificate the fake certificate needs to have both the same issuer information as the original certificate and result in the same SHA-1. If both is given this fake certificate is considered trusted same as the original one. Since the attacker has full control over the contents of the fake certificate he has also control of the issuer field and thus could set it as needed.


Can you hide your device from network scanner My router password has changed many times, so I am wondering if someone changed it. I used Fing to scan some device and no suspicious device was detected. But I'm still not sure if someone didn't hack it.

To 'hide' a device, you can put another device in front of it that changes characteristics. This is what proxies or routers do.

Or you can employ a filtering technique that only allows approved devices to get a response from the device.

But in your case, you are dealing with a router, which can't really be 'hidden'. Some routers have settings that allow you to restrict who can access the device. I'd suggest looking for the "WAN login" setting to turn off exposing the login page to the Internet.


What should I do when classified information stayed on a unauthorized laptop? Has anyone ever had to deal with an unauthorized laptop accidentally getting Top Secret level data on it?

How did you quarantine the system. Were you required to turn in the entire laptop or were you able to destroy/format the HDD?

NISPOM says that incineration or physical destruction of the HDD is required, but I just wanted to get peoples experiences with this type of situation.

Clarification:
the data was released to us as unclass (marked as such) and then was later found to have the class data on it. at which point they called us to lock everything down.

Conclusion:

laptops seized and we are told that the free space will be wiped after a forensic expert takes a look at it. if everything works out we should have our laptops and data back in a few days.

This an incident you need to handle and I am guessing that a standard response has not been detailed in your documentation.

Realize that your system is malfunctioning.  It is not operating the the way it was intended to.

Isolate your system [meaning your network(s) and physical facility if possible] to prevent the data from leaving your system. Take care to cause as little change to individual assets as possible. You want the state of the assets to stay constant until you can assess them.
Identify the source or sources of the data leak.
Isolate the leak source or sources to prevent further contamination in your system. Again, try to preserve there current state as much as possible. This will help you identify assets contaminated by the source.
Identify all assets that may have been contaminated by the source or sources.
Isolate the potentially contaminated assets. I know it is getting repetitive, but preserve the state of each asset as much as possible. These assets will help you assess the extent of the contamination.
Treat all potentially contaminated assets at the level of the contamination. In this case TS.
Verify that the remaining assets are not contaminated.
Breathe, have something to eat or drink, take a short break, because the rest of your day/week/month is going to be painful.
Discuss and plan remediation of contaminated assets. Planning well here will allow you to understand the scope of the problem, who is impacted, and how long you expect it to take.
Execute the remediation plan and periodically report on progress.
Pain
Vacation

  Has anyone ever had to deal with an unauthorized laptop accidentally getting Top Secret level data on it?

I have not. I have been involved in containment and remediation of sensitive data.

  How did you quarantine the system?

I have not been involved with the primary contaminated system, only secondary systems.

For systems suspected of contamination:

Posted restricted area notice sign on the door.
Locked the door.
Removed network communications.
Shutdown the system to preserve as much of the current state as possible.
Analyzed the system to check for presence of data in question.
If detected, moved the system to a secure area for sanitization.

  Were you required to turn in the entire laptop or were you able to destroy/format the HDD?

The agency involved will determine the action to be taken, and the policies and practices may vary from agency to agency.

I do not have personal experience, but given that TS is described as 'Such material would cause "exceptionally grave damage" to national security if made publicly available.' I would expect that every physical component of the item formerly known as a laptop will be crushed, smashed, melted, dissolved, extruded, shredded, and used as target in a artillery range.

The consequence of the release of the information compared to the value of the laptop, the other software and data on the laptop, and any other adjacent items of value, makes it clear that preventing the release of the data is worth the cost of total destruction of the laptop.


What SSL key should I make for IIS: RSA or DH? What bit length is appropriate? I'm creating an SSL cert for my IIS server and need to know when I should choose the Microsoft RSA SChannel Cryptographic Provider or the Microsoft DH SChannel Cryptographic Provider.

Question 1 Why would someone still need (what I assume is) a legacy certificate of 'DH'?

Given that the default is RSA/1024, I'm assuming that is the most secure choice, and the other one is for legacy reasons.

Question 2 Is there any guide to determine what bit level is appropriate for x device?

I'd be interested in either lab results, a math formula, or your personal experience. I know the different bit levels influence the time needed to secure an SSL session and that is important for low powered devices.

Question 3 How would bit-strength affect these scenarios?

My particular case involves these communication patterns:

A website that has powerful clients connecting and disconnecting the session frequently
A WCF website that sustains long durations of high IO data transfers
A client facing website geared for iPhones, and Desktops

RSA and Diffie-Hellman (DH) are just two different algorithms which accomplish a similar goal.  For most purposes, there is no overwhelming reason to prefer one algorithm over another (RSA vs Diffie-Hellman).  They do have somewhat different performance characteristics.  RSA is the standard choice, and it's a fine choice.

It's hard to give a one-size-fit-all recommendation on key size, because this is likely to be dependent upon your site's security needs, and because the key size affects performance.  My default recommendation would be to use a 1536-bit RSA key.  1024-bit RSA keys should be an absolute bare minimum; however, 1024-bit RSA keys are on the edge of what might become crackable in the near term and are generally not recommended for modern use, so if at all possible, I would recommend 1536- or 2048-bit RSA keys.
Note that many CAs have recently started deprecating 1024-bit end-entity certificates, as of December 31, 2010: they may issue you a cert for a 1024-bit RSA key, for legacy purposes, if you ask, but they are encouraging people to transition to 2048-bit RSA.  Some CAs are requiring 2048-bit keys, no exceptions.  Personally, I think 2048-bit RSA is overkill for most purposes and 1536-bit RSA is probably fine, but 2048-bit RSA is accumulating some inertia.

The larger the key, the slower initial connection establishment will be.  The most likely impact is on your server's load, since the server has to do a few public-key operations for each new device that connects to it (within a 24-hour period or so).  The public-key cryptography only incurs a one-time cost, which is paid once when a connection is created (and not paid again for any new connection within about 24 hours or so); the amount of data transferred over the connection is not relevant.

So, my default suggestion would be: select a 1536-bit RSA key, then test on a typical-low end client (e.g., an iPhone) to make sure performance is OK, then test whether your server can handle the number of connections per day associated with that key size.  If you have performance problems on the server, consider a crypto accelerator to speed up your server's performance.  If you still have serious performance issues, you could consider dropping down to 1024-bit RSA.  If you have a security-critical site, like a banking site, use 2048-bit RSA.


How do I identify a DES encryption key in a dump file using winhex? I've created a C# program that encrypts and decrypts a file. The encryption method is DES. The program is exactly the same as in the following link, except that the part that removes the key from memory has been commented out:

How to encrypt and decrypt a file by using Visual C#

My question is, after running the program and creating a memory dump, how do I identify the encryption key using winhex? All I can see are random bytes of data. Is just finding the variable name "sSecretKey" considered finding the key?

Without any knowledge this is a difficult task but not impossible. A DES key is random data with high entropy. Finding the key is something like trial and error. You are looking for random data in the memory dump and then you try to decrypt a ciphertext which you previously have been encrypted by using this data as the DES key.

This is a difficult task. I would suggest that you use a debugger. Set a break point right after the DES key has been assigned to sSecretKey. If the debugger stops the execution of the program at this point the DES key has been assigned to the variable and you can read it.


Do I need a PGP key? I'm new to OpenPGP, GnuPG, and the concept of public-private key pairs. I have some questions in my mind:

Is it necessary for me to have a PGP (or an OpenPGP) key? I'm an Android programmer, and an ordinary Linux user.
If yes, then, do I need only one PGP key, or I will need several keys for different purposes?
Is this belief true: Every today's computer user needs having, and using PGP keys?

From what I know about PGP, it's built on the concept of Web Of Trust, where trust is transitive. PGP belongs to public key infrastructure, and its main purpose is to provide ground for the authentication of public key, i.e. some public key truly belongs to a person who the key claim to belong. Authentication here is implemented by me using my private key to sign someone's public key, in order to authenticate they are the true owner of the public key. Since people who know me, and my public key in person, can verify my signing using my public key, then they would automatically 'trust' someone's public key which I signed. This poses a security issue when I mistakenly believe the key belongs to someone and I sign it. Then, my web-of-trust would automatically trust that malicious guy.
Since people in the web of trust usually know each other in person, which makes it very difficult to engage in, thus preserving some degree of privacy within the group.

So, coming back to your question, it all depends if such degree of privacy is needed, a group-level privacy, when deciding whether or not to use PGP.