OpenSSL - Generate self signed certificates with different cipher suites I want to generate a root certificate and SSL certificate (self-signed) for communication between an embedded device and our backend servers (IIS 8.0).

I used OpenSSL to generate a certificate with the following steps:

Here's how I created the root certificate:

openssl genrsa -out ca.key 2048
openssl req -new -key ca.key -out ca.csr
openssl x509 -req -days 7305 -in ca.csr -out ca.crt -signkey ca.key

Then I made the SSL certificate like this:

openssl genrsa -out mydomain.com.key 2048
openssl req -new -key mydomain.com.key -out mydomain.com.csr
openssl x509 -req -days 7305 -in mydomain.com.csr -CA ./ca.crt -CAkey ./ca.key -CAcreateserial -out mydomain.com.crt

This all worked fine.

After importing in IIS, I get the following supported cipher suites:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

My embedded device can only handle:

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256

I know the limitation is not in our Windows configuration or our IIS, because the sites hosted on that same web server (with our GoDaddy certificate), do support all 4 of these suites.

So I figure I must generate the certificate in another way. I just don't know how ...

The certificate you created misses the "Certificate Key Usage" extension with the property "Key Encipherment" enabled.

Therefore it isn't allowed for the server to use the RSA key in the certificate for the key exchange and as a result the server only offers Cipher Suites with Ephemeral Keys.


Does anything gets written to disk when doing a DLL injection? https://en.wikipedia.org/wiki/DLL_injection

My question: When someone is doing a DLL injection does anything gets written to disk? Or the whole attack is just in Memory?

DLL injection is a technique used for running code within the address space of another process by forcing it to load a dynamic-link library.

Address space is in Memory.

Now that's not to say that nothing will get written to disk. I could modify an executable in such a way that it loads xyz.dll on load. On the flip side of things, I could run my own project to inject code into the program to force it to load xyz.dll without writing anything to disk.

So the answer here is it depends.


How does a DNS provider provide SSL? I use CloudFlare as my DNS provider for my domain, and I learned that they provide SSL. I was confused as to how a DNS provider can provide SSL because my communications between the client and my website do not go though the DNS. I was thinking that somehow it becomes in between my website and the client, but then (besides them being able to read the packets) the communication between CloudFlare and my server would not be encrypted. How does this work? How can CloudFlare (as a DNS provider) provide SSL?

Cloudflare is not primarily a DNS provider but a Content Delivery Network (CDN). The DNS functionality is only used to make sure that Cloudflare can give an IP address of their own CDN server when a client wants to access your site. And this way the client will access the CDN server which then will access your server to get the content and serve it to the client. This means essentially that the client is not connecting to your  web server but to Cloudflare web servers and thus Cloudflare can provide whatever service they want at this hostname, including HTTPS.


In what ways do some banks inadequately advise their customers on online security? I'm looking for specific examples of things such as:

Misleading, but common advice
Advice which has backfired
Advice which is just, quite simply, incorrect

which have been circulated time and time again, to the detriment of customer security.

Banks have been urging the use of debit cards for years, but the policies around reimbursement after a fraudulent transaction are widely variable. It's one thing to have a fraudulent transaction sitting on a credit card statement, but it's quite another to have actual cash missing from your checking account and not be able to pay your rent. I always encourage people to use a good old-fashioned ATM card with no MasterCard/Visa logo; at least that way there's a PIN protecting you.

The notion that the "security picture" during login protects you from an imposter bank has been thoroughly debunked, and is a vestige of the previous FFIEC standards.

Banks tell customers that using security tokens like SecurID or Vasco can prevent malware-based attacks, but the reality is that the malware just sits there on the computer waiting for you to enter an OTP and then sends it to a waiting attacker in realtime. No protection there.

Finally, while login security is important, it's not enough. Most online banking fraud is traceable to malware, and the worst stuff just sits there and waits for you to log in before sending through unrequested transactions. The login can be as secure as you want, but unless you secure the transaction itself, you're still vulnerable.

One last thing - banks are still telling users that their SecurID tokens are completely safe. This is likely incorrect. If the attackers in March made off with all of the seeds, then the tokens are basically worthless. If they made off with only a subset of the seeds, the bank would need to find out for sure if their seeds were stolen. I've yet to hear any bank be able to make a claim on this point one way or another, so I assume any SecurID manufactured before this summer is owned. This doesn't apply to Vasco or anyone else, just to RSA.

Many banks simply do not understand these points, at least outside of their security teams, so the actual advice given out by customer service reps is often wrong on these points. I don't think it's necessarily the banks' faults; you can't expect every customer service rep to be a data security guru, but it does mean that the banks have a responsibility to deliver a secure enough system that bad advice from customer service doesn't matter.


Protecting Python source code on physical product? How would you protect Python source code on a physical product (like a IoT device), which comes with Ubuntu installed on a mini-PC running Python code?

Few methods we thought about:

Compiling the Python code (using PyInstaller, or other products).
Obfuscating the source code.
Linux-permissions-based solution: Configure a low-permissions user that can't even access the code, and the code running from a different user using the weak user's display.
Any other idea?

Anything you do to obfuscate your code is a waste of time. It can be reverse engineered and I promise you anyone that wants your intellectual property will take the time to deobfuscate it.

One solution you might look at is http://cython.org. Cython converts your python into C so that it can then be cross compiled for each platform natively. If you want to hide your code this is your best bet. I know of at least two companies doing this for production python code.


Privacy implications of Intel CPU backdoors I didn't follow all the episodes about backdoors in Intel CPUs

What can intelligence or law enforcement agencies potentially do on a computer equipped with a vulnerable Intel CPU (connected to the Internet but not directly - behind a router)?

Can someone continue to develop sensitive applications (using Linux) if the computer is equipped with a vulnerable Intel processor and his enemies are state-level actors?

You should catch up on these vulnerabilities in the canonical question on the subject.
Assuming you are talking about the recent wave of Spectre and Spectre-like vulnerabilities, those are not backdoors, but security vulnerabilities. They generally* allow a local process that is executing on your computer to read memory that they are not otherwise permitted to read. If your adversary is a nation-state actor though, this is the least of your concerns. These attackers usually have access to a large repository of 0days from security contractors. It's more likely that they will exploit a flaw in some exposed service on your router or computer and then escalate privileges using a 0day, known vulnerability, or misconfiguration on your part. If they had to use these vulnerabilities, they would use it to skip the privilege escalation stage and directly read memory.
Normally, a CPU executing code will eventually run into a fork in the road where the specific path it takes depends on some variable. If that variable takes some time to access (e.g. querying hardware peripherals or accessing memory that is not in the CPU cache), then the CPU will engage in an optimization technique dubbed speculative execution. This technique involves speculatively executing both possible paths in code, later discarding the path which it was not supposed to take. The Spectre vulnerabilities typically exploit the fact that this "discarding" is not perfect and still leaves some information behind that a side-channel attack can later discover.
* A few variants allow for a little bit more, such as covert side-channel communication and, in at least one example dubbed NetSpectre, attack certain theoretically vulnerable protocols to read memory over a network very, very slowly. Another variant allows setting read-only patches to read-write in certain, specific situations.


I have my website in wordpress and it got hacked how to secure it? Possible Duplicate:
  Protecting WordPress installations

i have control panel access to my wordpress website, but last week it got hacked and i found that the index.php was replced by the hackers file. I am amazed how did the hacker got the access of my folders without c redentials,

Can someone help me on this? How to secure my folders from hacking?

There are many ways to secure your Wordpress website.

First of all, you need to always keep an up-to-date version of wordpress. Very often, the Wordpress team produces a minor release that aims to fix several bugs and vulnerabilities.

It's probably how the attacker hit your website.

Now, if you search in Google, you'll find some interesting blog posts. I won't copy/paste here all the tips, but here are some good ones:

10 Ways To Secure Your WordPress Install
11 Ways To Secure Your WordPress Blog

You can also consider using this plugin :

Secure WordPress Plugin


Fingerprint ssh attack tool I noticed a high volume of SSH password attempts on my server and installed the Cowrie honeypot to see what the attacker(s) would do if they actually got access.

I've identified consistent patterns across many attacks that I believe are automated. Immediately upon identifying a working username/password, the remote system sends the following commands, with a 4 second delay between commands:

uname
free -m
ps x

then the remote system disconnects.

Another variant sends 2 commands per second, starting with those 3 and adding cat /proc/cpuinfo before disconnecting.

I would like to identify the tool/script/attack framework that performs these automated attacks. Does that behavior pattern look familiar to anyone? I have searched for likely candidates without success.

First, the pattern of behavior you're seeing is likely because the malware has detected that it's running in a sandboxed environment. CPU count for your honeypot should be greater than two, if it's not already because most new malware auto terminates if there are two or less CPU cores available, and the processes of your honeypot should not be visible to attackers' software because some of the better written malware will check if honeyd or other well known honeypot daemons are running or installed. An easy option for limiting process/fs visibility is to look up "firejail" and how to setup custom profiles.  Hint: strace output can be parsed and added to firejail profiles to hide/disable listing of host file system and running processes.

Second, look into running a Snort tap between your honeypot and its network connection to capture and fingerprint the attacks network traffic in near real time. I've had good luck with using Raspberry Pis for network monitoring for low cost.

Third, consider using dedicated hardware for your honeypot to make it look more like a legit victim; search term "system on a chip" (wiki has a list of manufacturer) for available cheap options. The one from Intel is the one I'd suggest for this because the architecture looks very close to a legit victims' desktop.

Fourth, look into Metasploit honeypot detection source code for kippo and others to make your honeypot less detectable because there maybe some other clever ways that attacks are detecting their being observed.

Fifth, checkout detection of metasploit reverse shells article using "carbon black" for after honeypot intrusion detection.  Be careful using the tools to hack them back; if you're going to try, do only the minimum investigation needed to identify the criminals.  Even if they attacked you first, it is still a crime to hack them back.


Which encryption method should I use when connecting multiple clients to a local server? Im am currently writing a project in C using OpenSSL/TLS and I am not very experienced in encryption. I have successfully established unencrypted OpenSSL connections and I am relatively experienced in C/C++. The Project involves the actuation of hardware so the data sent is very repetitive and not confidential (Just a few bytes, like turn commands for a servo or a temperature readout)

Basically I have multiple clients in a local network which I want to securely connect to a local server. The system has to work offline. All I want right now is to establish a connection between the client and the server to prevent unauthorized connections. Authentication and User restriction will be restricted by the application on the server.

I have been looking at Public Key Encryption but from my understanding that requires a connection to the CA which might not be available at all times. How correct is this and what are my alternatives?

A simple C implementation would be helpful too. Thank you

TLS is the right protocol for this purpose. There is no need to have an internet connection with TLS (i.e. your requirement to be offline) but you can use TLS either with self-signed certificates (simple but does not scale well) or have your own certificate authority (more complex but scales well).

  A simple C implementation would be helpful too.

Using plain OpenSSL for TLS in a proper way is usually not simple. There are many sample implementations on the web but they often suffer from insufficient certificate validation. If you implement it yourself you should make sure that

the trust path, expiration etc is checked properly. That's what most samples already do because it can be simple done with OpenSSL. See https://wiki.openssl.org/index.php/SSL/TLS_Client for an example client.
the subject of the certificate is checked against the expected one. That's what most examples don't do because it was too complex with older OpenSSL versions. But, not doing this makes you open to man in the middle attacks. See https://wiki.openssl.org/index.php/Hostname_validation for how this can be done.
in case of a PKI instead of self-signed certificates the revocation needs checked either against a CRL you need to download from somewhere or against OCSP. This is almost never done and too complex with OpenSSL. I don't know if any sample code for this.


How can you change platform / OS that is detected by JavaScript in Firefox? Going to https://panopticlick.eff.org/ this site knows your exact OS / platform and changing user agent doesn't help because JavaScript is used here.

Is there a way to change / fake it anyway?

I have found a script on this site but it doesn't seem to work

// ==UserScript==
// @name        Faker
// @namespace   x
// @version     1
// @grant       none
// @run-at document-start
// ==/UserScript==

var fake_navigator = {};

for(var i in navigator) {
  fake_navigator[i] = navigator[i];
}

fake_navigator.platform = 'Linux armv7l';

navigator = fake_navigator;

I have tried to run it on Firefox using Greasemonkey but I still keep getting Win32 as my platform (my original one..).

That code is outdated / I run it wrong? Any other ways maybe?

The navigator object is accessed via window.navigator which is in fact a read-only property.

Therefore navigator = fake_navigator; will not work.

However, it is possible to redefine the getter for platform:

navigator.__defineGetter__('platform', function(){
    return 'foo' // customized user agent
});

Querying the property will then return the value within the function.

window.navigator.platform
"foo"

This will fake your platform as far as the JavaScript property is concerned, but Panopticlick is about fingerprinting your browser as a whole, not just taking one property and identifying you through that. Therefore, if you are doing this for privacy reasons then I would not recommend this as an effective measure.


Facebook oAuth2 for Javascript client application When implementing Facebook login using oAuth2 (the Javascript version), I receive an access token back from the Facebook auth server. So far so good.

The problem I have is that I want to implement a RESTful back end, where the user needs to authenticate on every request for accessing a back end resource, using a server generated token. What happens is that when using the standard login on my website (email + password), this token gets generated on the server by my own application and is then sent to the front end where it is stored (all transactions happen over https).

So I thought about using the access token that I receive from Facebook to store it in my back end, if the user wants to log in using Facebook. This way, every RESTful request to the back end could be checked against this token.

The problem however, is that the back end cannot check if the token received from the client is a valid Facebook access token (this is a Javascript client application, heavily relying on Ajax for all server communication).
Even though I can write Javascript to only send the access token to the back end on successful authentication with the FB server, this process is not reliable as the Javascript is not protected.

My question is:

  How can I safely store a token in my back end, after the user
  authenticated with Facebook?

Please note that I am creating a Javascript application using Backbone.

Edit: I changed the workflow for the login. If a user would have multiple third party accounts, and each account uses a different email address, then the email address is not a valid identifier. Now I'm using local userId.

1) When the user wants to log in using a third party access such as Facebook or Google, then the client requests an access token with Javascript to the auth server of this party. When the resource owner (user) is authenticated, the userId (and other related data) is returned in the response, together with the access token.
This token is stored at the client in the form of a persistent time-limited cookie (eg 60 mins);

2) The client sends an Ajax request to the Zwoop server, sending the 3rd party (FB / Google), the 3rd party userId, and the access token with a POST request;

3) The Zwoop server receives the Ajax request, and sends a request (with PHP) to the 3rd party auth server (based on the the one defined in the ajax request) to get the 3rd party userId, based on the access token (that was received from the ajax request).
When the userId’s match is successful, the Zwoop server has verified that the client has sent the correct credentials.

This approach makes that the oauth2 access token functions like a password, and is verified in the back end against the third party's Auth server. No malicious user should be able to simulate the same combination of credentials and the communication happens over SSL (no eavesdropping);

4) After the userId - token match verification was done at the server, the local userId can be retrieved and returned to the client.
The local userId is the userId that Zwoop defines.
For all further requests for resources to the Zwoop back end, we use local userId rather than the third party userId, this is why we retrieve it in this step.

The token can now be saved in MySQL and the Zwoop userId + token can be cached in Redis / memcached.

5) The Zwoop local userId is resent to the client.
We use the local userId for further requests to the back end.
We only use the third party userId in case we need access to specific third party resources (eg. Facebook newsfeed, calendar, etc...).
If the authentication fails, then the userId will not be sent;

Further RESTful requests can now be made, whereas the oAuth access token (client) is matched against the cached token (server), to identify if the user has permission to access certain resources in our own application;
When the cookie or access token expired, the client will request a new one, and the same procedure repeats itself.


Securing an automatic updater Scenario

You have a launcher for some software, it allows you to execute the software but it will also allow you to switch versions and upgrade to newer versions.

When the launcher is executed, it downloads a manifest file from a specific URL (built into the launcher) to fetch the current list of versions. If there is a newer version, the user is notified and can update. If they decide to update to the new version it will pull another manifest from the same host as before, this is the manifest for the specific version.

This file contains a list of file names contained within this version and their respective SHA1 hashes. The patcher will then connect to the same host again to download files whose hashes do not match the local copies.

All manifest files and file objects for each version are stored within a single S3 bucket in this example. All requests are made over HTTPS to gzipped files.

Flaws?

I feel like this would be open to attacks due to semi-automatic downloading of executables. I don't know where an attacker could get in though. Should all files on the remote server be signed? Or will verifying the file contents with the SHA1 hashes provided by the server be enough?

Is there anything I can do to keep this safe, or should this kind of technique be avoided completely?

You have to consider what an attacker might do. He can grab your update file, inject it with malware, compute a SHA hash, deliver it to one of your clients, and infect them. Their computer would not reject it if it's only looking at hashes.

If your app only accepts signed files, he cannot infect them.

But checking individual files may or may not be enough, depending on your code. If you only test your code as a whole version, the attacker could possibly find an interaction bug by mixing an older version of one of your modules with your newer code. You should consider signing a collection of modules at the same grouping you are willing to test and deploy at. That way, you deploy only the tested change as a whole, never piecemeal.

This kind of attack was perpetrated against Microsoft Update. Someone could download the list of modules but then interfere with the downloading of the actual modules.

Not only could this approach reduce your attack footprint, it could serve to improve your end user experience by ensuring they are installing complete packages that are exactly what you tested. It might even help keep them out of "DLL hell."


How secure is Windows 8's Picture Password login? The final Windows 8 build has been released to manufacturing. One of the new features of Windows 8 is  "Picture Password", where the end user logs on to Windows by clicking a specific pattern on the lock screen. (For readers unfamiliar with the feature, this 4 minute video illustrates it.)

From a pure security standpoint, what are the pros and cons of a picture password scheme versus traditional password entry?
Is there a rough approximation to how picture password 'clicks', 'circles' and 'lines' correspond to password length, i.e. how many bits of entropy do the picture password gestures roughly provide?

Potential weakness: predictable passwords.  I expect the primary weakness is likely to be that users choose a "picture password" that is guessable or predictable.  If the user chooses a predictable set of locations/gestures, someone may be able to guess the "picture password".
For Microsoft's evaluation of their own design, you should read this Microsoft blog post on the security of Windows Picture Password.  They provide some simple calculations to estimate the strength of a picture password, and to estimate how many bits of entropy they provide.  However, I think their security analysis is overly optimistic, because they make several dubious assumptions:

First, they assume that all locations in the image are equally likely to be chosen by the user.  I think this is unrealistic; for any given photo, I think some locations are more likely to be picked than others, which it will be predictable which locations are more likely to be picked.  Someone is probably more likely to choose some unique feature in the picture, not a random location in the middle of a broad expanse of blue sky.  For instance, in the video you shared, the user chose to tap on the location of a window in the image.

Second, they assume that the location of the user's three gestures are all chosen independently.  In practice, I don't think this is realistic; I think there will often be some pattern.  For instance, in the video you shared, the user chose to tap on three windows in sequence.  If you've guessed that the first tap location is over a window, then it would be natural to guess that maybe the next two are on some other windows, too.

Third, they assume that users will use a combination of taps, circles, and lines.  (They have three kinds of gestures: tap on a specific location, circle around a particular location with some radius, or drag your finger in a line from one location to another location.)  However, tapping is the quickest and easiest and most natural of these gestures.  Therefore, I would suspect that many users will just tap on three locations, and not bother with the other gestures.  At the same time, tapping has the weakest security, because of the limited number of locations on the picture that someone is likely to select.  Therefore, I think some of Microsoft's calculations about security level may be based upon a somewhat optimistic view, and users may not behave the way they are assuming.

As a result, I suspect that the entropy of picture passwords might be significantly lower than the estimates found in those Microsoft blog posts.
Microsoft has a follow-up blog post where they give advice to users on how to choose a hard-to-guess picture password, but I'm not persuaded that the average user will be aware of this or will bother.
That said, Microsoft has deployed one very significant defense against guessing attacks: you only get 5 tries to enter the picture password.  After 5 tries, the system locks you out and requires you to enter the textual password.  Therefore, someone who gets ahold of your phone will only get 5 tries to guess your picture password -- and if they don't get it right within 5 guesses, they're done.  If implemented properly, this seems like a powerful and effective defense against guessing attacks.
Potential weakness: the weakest-link effect.  There are now two ways to log into your account: either enter the text password, or enter the picture password.  If an attacker can guess either one, he can get access to your account.  Therefore, your security is only as good as the weaker of those two passwords.  To be secure, both of them need to be well-chosen.  This might trip some users up.
Potential weakness: smudge attacks.  Suppose someone gets ahold of your phone.  Another way they could try to guess your picture password is by looking at the pattern of smudge marks on the screen left by your finger oils.
Past research has looked at smudge marks, in the context of phone lock screens.  They found that this attack can be surprisingly effective.  If you hold the phone at just the right angle to the light, you can often see the smudge marks clearly.  And if they use a digital camera to take a picture at the right angle, the smudge marks become even clearer.  Amazingly, they found that the smudge marks remained clearly visible even if the user put the phone in their pocket -- you might expect this would wipe the fingerprints off, but nope, they still remained visible!
The research is described in the following paper:

Smudge Attacks on Smartphone Touch Screens.  Adam J. Aviv, Katherine Gibson, Evan Mossop, Matt Blaze, and Jonathan M. Smith.  WOOT 2010.

While I haven't seen any work on this in the context of Windows picture passwords, I would expect that similar methods might help an attacker guess the picture password and significantly reduce the entropy in the password.  Fortunately, the attacker only gets 5 guesses, which should help make smudge attacks harder.
For instance, suppose the attacker gets lucky and there are only 3 smudge marks on the screen.  Then there are 3! = 321 = 6 possible re-orderings of these.  The attacker gets 5 tries to guess the picture password.  So, in this scenario, the attacker has a 5/6 chance of guessing the picture password correctly before being locked out.  That said, this is almost the best possible case for the attacker, and in practice, the attack will likely be harder to mount, because the attacker will have to guess which of the smudges come from the picture password and which ones come from other use of the touchscreen.
As a lower-tech and more-extreme version of this attack, consider the following photograph of a PIN-entry keypad:

Can you guess the PIN, based upon the wear pattern on the keys?  Yes, very good, I knew you could!
Potential weakness: shoulder surfing.
Another possible attack is that, if someone is looking over your shoulder when you log in, they will find it very easy to notice where you are tapping.  In fact, it will be hard not to notice the picture password being entered.  So, entering your picture password while you are in view of someone else is not safe.
Advantage: convenience.
I expect the picture password to be easier for users to use and more convenient.  Right now, all of the methods for authenticating on mobile/touchscreen devices are a pain in the butt.  Entering a text password on a touchscreen keypad is a horrible experience, which just drives users to choose poor, short passwords -- and that's not good for security.  So, I expect picture passwords will be good for users.
Advantage: no worse than the alternatives.
Right now, on mobile platforms, the main alternatives are asking the user to enter a 4-digit PIN or asking the user to use an unlock gesture, as is done on Android or the iPhone.  However, those have their own security weaknesses as well, and they may be no better than the Windows picture password.
Therefore, for mobile platforms, the Windows picture password may represent a pragmatic and reasonable tradeoff between ease of use and security, one that is sufficient for the average user.
Conclusion and takeaways.
My personal impression is: it seems like a plausible scheme, one that might be adequate for many or most users.  Overall, it feels like a pragmatic choice to me, given the engineering constraints -- I would be hard-pressed to try to come up with something better.  However, it is a new scheme, and more research will be needed to better understand how secure it is, in practice.  The security of the scheme will depend heavily upon how users use it, and it's probably too early to say whether it will work well for typical users or not.
Related schemes.
To read about other schemes for authentication on mobile or touchscreen devices, see Are the iPhone “connect the dots” passwords secure? and Is Android's Password Screen Lock Enough Data Theft Protection?.


Can someone tell if you are using a VPN by your IP address? I am wondering whether a website you are accessing can tell if you are using a VPN or not based on your IP address? I have done some Google research and it appears, that this is the case.

However, I am not exactly sure whether it is different if you use a dedicated IP from a VPN service instead of a dynamic IP address. Can it be possible that your IP looks like a "private" IP from a private household?

If you use a public VPN service: Yes.

You know it's a VPN; so can a third-party.

Dedicated IP reduces the problem but doesn't eliminate it, as an agency could simply ask for all IPs controlled or purchased by the VPN provider; or infer it from Whois/DNS contact details or monitor propagation of software patches from a known VPN company to any server.

If you create your own private VPN: No.

At least if you don't specify what precisely you are using the box for and your VPN software doesn't leave open obvious ports or phone home for patches.

Regarding IP spoofing: Most ISP routers reject spoofed IP packets nowadays, so that option is ruled out. If you start using onion routing then you have really replaced one VPN with multiple VPNs


How can we guarantee our custom auth implementation to a client? Context
In .Net 4.6 my team used Microsoft's built in authentication/authorization systems primarily through its Owin tools. In .Net Core Microsoft decided NOT to port that segment of tools. So, we made the decision to write our own auth middleware to generate, authenticate, and authorize JWTs in our .Net Core apps.

Note: We were careful to ensure we followed OAuth standard very closely

The Question
Is there any 'stamp of approval' for our custom auth middleware we could have to assure client's our application security is trustworthy?

The Scenario
The idea is that a client could come to us and say 'what kind of security are you using on our app?' We would explain the security pipeline used in there app and include our custom auth in that response. Then they could likely respond 'Custom auth middleware? That sounds dangerous, how can you assure us its secure?'

The Posibilities
What were searching for might be a certificate, it might be just to say that our auth system follows a particular standard. Or maybe, there is nothing at all and the best we can do is just say 'trust us, weve done this before... -_-'.

If you have the money get a pen test of the system from a reputable firm.  Lots of firms are available (e.g. Synopsys/Cigital, Rapid7, SEC Consult, etc.).  Expect it to cost you $40K to $50K USD.

Then you can either show the test report to your customer or you can tell them that you had it pen tested it no issues were found.  Be careful about showing reports to customer, if you do it once they'll expect it from then on.  My company will not show pen test reports to a customer, but will characterize them (e.g. "X highs were found, Y mediums, and Z lows and all have been remediated").


How does a "fake" network-adapter steal credentials? I've read that devices that look like USB flash drives can be hidden network cards that can then steal credentials even when the screen is locked. (Like the Bash Bunny)

I understand that being the network they can send internet traffic anywhere. But how would that help? I can even understand that if someone is willing to type their password into a non secure site (http) - they can read that. But as long as https is used (and I assume automatic traffic like Windows Update for example, even if they would send some credentials, would be over TLS) how would they read that? And besides, why would any automatic traffic send credentials?

So my question is how can a hidden network card steal credentials when not being used by a user (e..g. when the screen is locked)?

The attack you read about is probably PoisonTap. Basically it works by the USB device being a small computer which emulates an USB network adapter and provides IP address and routes so that most of the network traffic of the attacked computer gets send to the USB device.

Getting credentials this way is possible since browsers continue to run if the screen is locked and they continue to update sites in the background. PoisonTap provides such "site updates" and includes links to even more sites inside the update so that lots of sites gets accessed. And it provides the content for these sites too etc. The requests to the sites where the user is currently logged usually include a session cookie which often can be used to impersonate the user. Sometimes requests also includes the original username and password credentials, for example if basic authentication is used by the site. And, if the victim is using a password manager which automatically fills in credentials the attacking USB device might return pages which include login forms and some Javascript and thus extract the automatically filled in credentials.

Note that this works only for HTTP and not HTTPS since the attacking USB device does not provide trusted certificates for the sites in question. Still, not all sites use HTTPS and some times will provide the session id also if the target URL is HTTP only (i.e. no secure flag set on cookie).


ssh-keygen: What is the passphrase for? When using ssh-keygen:
What is the passphrase for?
Why is it optional?

What are the security implications of specifying (or not specifying) one?

Below is an excerpt taken from a shell session
(some details may have been altered):

user@localhost:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /user/.ssh/id_rsa.
Your public key has been saved in /user/.ssh/id_rsa.pub.
The key fingerprint is:
60:8b:50:1e:0f:bc:5a:2a:13:1e:83:2b:d9:95:38:9e user@localhost
The key's randomart image is:
+---[RSA 2048]----+
|   .+            |
|   o.+           |
|. ...o+          |
|ooo.=o o         |
|.*oB. . S        |
|*.E              |
|.o               |
|                 |
|                 |
+-----------------+

$ man ssh-keygen
[...]
It is possible to specify a passphrase when generating the
key; that passphrase will be used to encrypt the private
part of this file using 128-bit AES.

So this passphrase just encrypts the key locally. An attacker with access to your system will not be able to read the private key, because it's encrypted. (They could install a keylogger, though.) If your laptop is stolen for example, your ssh key might still be secure if you have a strong passphrase. Or even with a fairly weak passphrase (so long as it is not trivial), it will buy you some time to revoke the key and roll over to a new one, before the attackers can crack it.

It's optional because you can choose to accept the risk of having it not encrypted in storage. Or perhaps you have disk encryption enabled, which mitigates some of the same attacks (but not all, for example: malware can still steal the key, even with disk encryption; on the other hand, a stolen laptop is still secure unless stolen while running with the key in memory).

The server can require the use of both a public key and a password to log in. The security of this is different from using a password-encrypted public key. If you use an encrypted key, then:

you cannot change the password on the server side, you'll have to generate a new key;
someone might crack the key's password undetected, because they can do it offline (if the server requires a password, they have to ask the server "is aaaa correct? Is aaab correct?" etc.);
someone can crack the key much, much faster because it's an offline attack without network limitations; and
the server cannot use something like fail2ban to reject too many login attempts, because the cracking happens offline.


Is it a good idea to use non-ASCII names in the U.S.? Grimes and Elon Musk named their baby: X Æ A-12.

What are the risks of non-ASCII names?

For example, does the COBOL unemployment platform support non-ASCII names? Would it be possible to get a social security number (SSN) for the baby? Does it make their baby an easier target to impersonation attacks using Unicode manipulations? Could the baby name trigger a code injection attack?

Clearly pure-ASCII names might cause issues: too: \0, ^Z, NULL, etc.

There are even Chinese people in the US. They name their children 李某. Would that be a problem? No. Some systems support these names, some use versions converted to ASCII through romanization (李某 → pinyin Lǐ Mǒu → Li Mou). The only non-ASCII character in X Æ A-12, Æ, is used e.g. in Danish names like Ægidius, converted to ASCII Aegidius.
A good example of such conversion is machine-readable passports: the last two lines on every passport contains only characters A–Z, 0–9 and the filler character <. For passports, every name in the world gets converted to ASCII.
Sometimes using mere ASCII may be more problematic than non-ASCII characters that are easily encoded in UTF-8:

Christopher Null is a real person who has reported some problems with his ASCII name.

My name is Logger, Startkeylogger.

Little Bobby Tables has a name as unique as the little baby Musk. This Robert doesn't have a social security number as he's a fictional character, but for real people the name isn't an obstacle.


Can format string exploit bypass the PaX protection? I'm trying to find info regarding how format string exploit can bypass the PaX protection mechanism. As I understood PaX just features ASLR and NX protection. So I wonder if an attacker should use string format exploit to bypass PaX. Is it because you can print out the stack with format string? However it doesn't necessary helps since next time the stack will look differently because of PaX's ASLR mechanism.

So I wonder how one would bypass PaX if format string attack is used. I assume that no other than PaX protection is currently on.

Format string vulnerabilities can aid in exploitation of systems protected by ASLR,  but not NX.   The reason why is because some  format string vulnerabilities allow the attacker to read the function's stack frame, that contains the format string vulnerability.  This allows the attacker to figure out the addresses of variables local to that function by reading the stack frame.    ASLR randomizes the memory page's base address at the start of the application.  So on a 32 bit system the address looks like 0xYYYYZZZZ.  In this case the Y's will be randomized,  but the Z's are an offset that is more predictable.  (Ideally) If the attacker can read the randomized base addresses of the same function that he is exploiting with a buffer overflow then the attacker can be 100% confident of the address of where his shell code will be.  If its not in the same function, then attacker is less confident of the address of his shell code,  but it can still aid in exploitation.  After determining the address of where the shellcode will be the next step is to corrupt the stack frame with a buffer overflow and point the EIP at this known memory location.   Which to be honest is really far fetched and not many exploits use this technique.   This technique is covered in great detail in "Exploiting software how to break code"  and in "Hacking: The Art of Exploitation".

There are other ways of reading memory addresses.  In the pwn2own for IE in 2010 a researcher used a heap overflow to overwrite the null terminator and read adjacent memory, he then obtained code execution with a dangling pointer.  Dangling pointer vulnerabilities are really nice for systems protected by ASLR and they are becoming more popular for this reason.

If you look at most of the exploits hitting Metasploit and the exploit forms.  You'll see that Return Oriented Programming(ROP chains) is the weapon of choice for exploiting buffer overflows on modern systems.


Security design behind google's application specific password When using Google's two-step verification with services that can't use it, such as mail clients on smartphones and desktops, the solution is to create application-specific passwords for those services.

Does that make things less secure than just using one password as this opens up the account to more that one password?

Google's application specific passwords are random and quite long. Those passwords don't occur in any dictionary and cannot be brute forced. So, they are very strong, typically stronger than any password chosen by humans.

Using different passwords for different applications usually increases security. Since, if a password is leaked for one application it cannot be used for another appliation.


Secure MacOS against malware and external threats? Often I am required to connect to public wifi or open files that others send me. Doing so opens me up to possible credential theft as well as possible viruses or malware.
Thus far I have done my best to lock down the system by enabling firewall, installing a reputable malware scanner (Malwarebytes), and enabling device encryption.
What would be the next step to keeping my device safe against threats or is what I have implemented be satisfactory for a general user? What common attacks could my system be open to?

Fix your attack vectors
You identified that your behavior opens you up to attacks. Instead of trying to counteract these attacks, make them impossible in the first place.
Instead of using an open access point, consider connecting your phone via USB and use your phone's internet access instead. Alternatively, consider investing in a SIM card adapter for your laptop so you can connect to the internet like that directly.
As for opening files, what nature are these files? Images, archives, executables, etc...?
Depending on their nature and their requirement for confidentiality, uploading them to VirusTotal before opening them may already be enough. If they're confidential executable files, consider creating a virtual machine environment to run them in.

Edit: You've mentioned that you primarily open images, PDFs and spreadsheets, so I will give a bit more information on each.
Images are usually harmless, since they don't execute any code. While there are indeed images designed to exploit vulnerabilities in the libraries that decode image data, such as Bannerbomb on the Wii and Stagefright on Android, these are usually very rare. With an up-to-date operating system, you should not be affected - or at least, just as affected as everyone else.
Spreadsheets are a bit more dangerous, since spreadsheets can contain macros. Excel and CSV files can contain malicious formulas, which lead to remote code execution. While this is indeed severe, spreadsheet software these days warns you several times that this is really dangerous and you should only allow that if you trust the document and its source. Spreadsheet software can also be configured to never allow DDE, which is used in these kinds of exploits.
Furthermore, since you mentioned you were on MacOS, Apple has its own spreadsheet software called "Numbers". I have to admit that I don't know anything about Numbers or the possible ways to exploit it. However, I would assume that the situation is similar to other spreadsheet software.
PDF files are even more dangerous, since they can embed all kinds of data. This question goes into detail about the dangers of PDF files. The mitigation is again to keep your reader software up-to-date and to check with VirusTotal if you are unsure about the file.


Is port forwarding inherently unsafe? I had an argument with a person a few months ago when I proposed we forward port 12xyz to an internal SSH server.

The target server was tied down in a manner similar to the one recommended by @stribika at https://stribika.github.io/2015/01/04/secure-secure-shell.html. Specifically, no root access, public key authentication only, non-standard ssh port, high-quality ciphers, kex, and, macs.

I was arguing that the forwarded port was not inherently dangerous in itself, and that the safety was dependant on the service at the target port. I maintained my method was a perfectly safe way to gain remote access. He vehemently argued that it was not, stating that a VPN tunnel is the only safe way to achieve remote access.

Who was right?

Forwarding ports is NOT inherently dangerous in itself and YES the safety is dependant on the service at the target port. But safety also depends on how good is your router's firewall and how well it is protected, both internally and externally.

For remote access, both SSH and VPN works as good as each other. Neither is more secure than the other when similar levels of encryption are used. But since SSH works at application level, supports only TCP and provides remote access to a single computer only I would prefer VPN tunnelling which in fact works at the transport layer, supports both UDP and TCP and allows secure access to multiple resources.

VPN tunnel is NOT the only safe way to achieve remote access, but definitely the preferred way due to the above reasons. Not to mention SSH is really difficult to implement properly in case of multiple resources, can cause DNS leaks and has to be configured separately for each application.


Spoofing UDP checksum using scapy I'm trying to play with a security tool using scapy to spoof ASCII characters in a UDP checksum. I can do it, but only when I hardcode the bytes in Hex notation. But I can't convert the ASCII string word into binary notation. This works to send the bytes of He (first two chars of "Hello world"):

sr1(IP(dst=server)/UDP(dport=53, chksum=0x4865)/DNS(rd=1,qd=DNSQR(qname=query)),verbose=0)`

But whenever I try to use a variable of test2 instead of 0x4865, the DNS packet is not transmitted over the network. This should create binary for this ASCII:

test2 = bin(int(binascii.hexlify('He'),16))

sr1(IP(dst=server)/UDP(dport=53, chksum=test2)/DNS(rd=1,qd=DNSQR(qname=query)),verbose=0)

When I print test2 variable is shows correct binary notation representation.

How do I convert a string such as He so that is shows in the checksum notation accepted by scapy, of 0x4865 ??

>>> test
'0b100100001100101'
>>> type(test)
<type 'str'>
>>> test2
18533
>>> type(test2)
<type 'int'>

bin() returns a string.  Remove the bin() to get an integer, and use that for the chksum input.  The following sent out the packet correctly for me:

from binascii import hexlify
from scapy.all import *

test2 = int(hexlify('He'),16)
send(IP(dst='127.0.0.1')/UDP(dport=53, chksum=test2)/DNS(rd=1, qd=DNSQR(qname="query")),verbose=0)


How difficult to crack keepass master password? How easily could someone crack my keepass .kdbx file if that person steals the file but never obtains the Master Password?

Is this a serious threat, or would a brute force attack require massive computing time?

Assume a password more than 10 characters long with randomly distributed characters of the set including all letters, numbers and most non-alphanumeric keyboard symbols.

KeePass uses a custom password derivation process which includes multiple iterations of symmetric encryption with a random key (which then serves as salt), as explained there. The default number of iterations is 6000, so that's 12000 AES invocations for processing one password (encryption is done on a 256-bit value, AES uses 128-bit blocks, so there must be two AES invocations at least for each round). With a quad-core recent PC (those with the spiffy AES instructions), you should be able to test about 32000 potential passwords per second.

With ten random characters chosen uniformly among the hundred-of-so of characters which can be typed on a keyboard, there are 1020 potential passwords, and brute force will, on average, try half of them. You're in for 1020*0.5/32000 seconds, also known as 50 million years. But with two PC that's only 25 million years.

This assumes that the password derivation process is not flawed in some way. In "custom password derivation process", the "custom" is a scary word. Also, the number of iterations is configurable (6000 is only the default value).


What regulations *require* multi-factor authentication? What industries require multi-factor authentication?

Please include the following information:

Country
Industry
Regulation name
Additional information as you see relevant.

Some additional information I'd like to know is how the regulation "defines" multi-factor.  This is of concern because the 2005 FFIEC regulations allowed a browser cookie to act as a second factor according to a surprising recent legal ruling.

This is kind of tangential to the question, but that courthouse is in walking distance for me so I followed the PATCO case closely (and the defense lawyers are across the street from my office).

The magistrate's logic is horrid... and unfortunately a judge accepted that recommendation, so that particular case was decided. However, (US legal theory) this is a district court, not an appeals court. The decision is not a binding precedent in future cases in any part of the country.

I referenced that case earlier when writing up an answer on muti-factor authentication for How is "something you have" typically defined for "two-factor" authentication? If another case were to come up involving similar questions, the logic whether cookies can qualify as "something you have" would be argued anew, though I'm certain at least one side would point to this case.

Assuming there isn't a definition that is relevant to the case (much like the FFIEC didn't define this particular question), a judge would decide how that should be interpreted in the context of a case based upon expert testimony.

With the above considered, I don't know of any legal standard, ruling, or precedent in law that defines the boundaries of what different systems qualify as which factors of authentication.


Is UAC enabled and set to Elevate without prompt actually a security protection? Does enabling UAC and setting the Admin approval behavior to Elevate without prompting provide any form of extra security to Administrator account. Note that my use case is for a Kiosk application where user interaction in Admin mode is very less.

UAC was implemented as a way to control who installed software on a device and not really as a security measure.  It's more of a management solution than a security solution.

WRT the Administrator account: that should be used only sparingly.  A more secure solution to that would be to rename the account and then disable it, then create other Administrator-level accounts for specific users.


Does the Kerberos KDC know the users' plaintext passwords? In http://www.freebsd.org/doc/handbook/kerberos5.html section 15.7.8.3 “The KDC is a Single Point of Failure” you can read:

  By design, the KDC must be as secure as the master password database is contained on it. The KDC should have absolutely no other services running on it and should be physically secured. The danger is high because Kerberos stores all passwords encrypted with the same key (the “master” key), which in turn is stored as a file on the KDC.

Doesn't that mean that this is an Achilles' heel of Kerberos since if the KDC is compromised, the attacker will know all users' plaintext passwords (as opposed to getting /etc/shadow of a Linux system which will only provide the attacker with the hashed and salted passwords)?

The short answer is: no.

It knows a secret key that may be derived from the user password. The specification RFC 1510 says in the introduction of section 6:

  It is desirable for the string to key function to
     be one-way, and for the mapping to be different in different realms.
     This is important because users who are registered in more than one
     realm will often use the same password in each, and it is desirable
     that an attacker compromising the Kerberos server in one realm not
     obtain or derive the user's key in another.

Note that there is no random salt unique for every account, just the realm name which is shared among all users of the same realm.

The updated version RFC 4120 allows other way to derive the key:

  The user key might be stored on a smart-card, or otherwise obtained independently of a password.


Is it risky to buy refurbished phones? At least in theory, when buying a refurbished phone, is there a chance the phone has been modified, in the same vein as phishing, to look like a stock installation, down to the "factory reset" and maybe even appear rooted?

I.e., if a company bought 300 refurbished phones off eBay...

I suppose running Wireshark to see what's coming in or out might be a good start but I am hoping someone will say it's extremely unlikely (given that nothing's impossible).

Is it possible? Of course, see the examples above and probably below.

Is it likely? Depends where you buy them.

If you buy random, too cheap to be true, refurbished smart phones from a nonreputable chinese vendor on ebay your chances of running into a smart phone with malware increase exponentially.

Unlike some stories about hacked devices and such, this is something that could be worth the hackers while though as today a lot of people will have banking, facebook, authenticator, etc apps on their phone so the attack vector is very real I would say.

On the other hand, to add some realism, buying a refurbished phone from a reputable source like a big brand, well known web shop or similar (you know the brands for your own country / area best) I'd imagine the risk isn't that high.


How safe can connecting to VPN really be? I would like to make this story as short as possible since my question is not that long, I have worked with journalists previously in war zone where we investigated the involvement of EU IT companies in selling monitoring software to Dictator regimes owned ISP companies, One was a french company that I can't mention their name nor their software but the software was capable of simply monitoring anything from clients PCs even if it was encrypted.. it would be decrypted.

So my question is in case of being connected to VPN with SSL support and Certificate server/client verification plus user authentication. how secure can user's browsing be?

Is it possible for the ISP company that user is connected to, to know what anyone is browsing regardless if he/she is connected to a secured VPN connection?

Connecting to VPN and using the Internet in the scenario you described is actually very secure. In the case you're talking about (mutual authentication), it is safe to say that ISPs aren't able to intercept and eavesdrop on the connection to know what the user is doing.

However, in the example you made about war situations, government agencies don't just rely on ISPs intercepting connections. An example with which I'm quite familiar is the Syrian civil war. Regime agencies, supported by Russian and Chinese tech and advisers, have actively tried much more invasive methods.

Kaspersky has published a report detailing those invasive methods. They include malware disguised to look as if it contains important information to press or opposition (wanted activists names, lists of imprisoned members of the press, etc.), web pages serving malicious code, documents containing exploits, and a number of other methods. They mostly rely on social engineering.

To put in one line: Yes, that VPN scenario sounds pretty secure. However, in a broader context, only taking care of VPN will not guarantee you the security you're looking for.


Preventing XSS by filtering data from the server to the client Before you immediately comment "you can't trust the client!", please read the whole question.

I've been reading about how to prevent XSS attacks lately, and everything I've found says that the server should sanitize the data that will be put into the webpage. This would basically look like addToDatabase(filter(userResponse)). Then the client can safely add display anything that it gets from the server.

I was wondering if it would be safe to store the potentially unsafe data in the server, and have the client filter it when it was received, like addHTML(filter(serverResponse)). This would stop the data from being executed client-side, so no XSS would take place. I understand that anyone could simply remove that filter, however all that would do is make themselves vulnerable. Since other clients would filter anything sent to them, a malicious client could could only disable their own filter and mess up themselves.
(I'm not talking about SQL injection prevention, that would be obviously have to be server-side)

To summarize: The server doesn't sanitize, but the clients sanitize whatever they receive.

Would this be safe?

The answer is at the point where you're generating HTML, is where HTML encoding/sanitizing should occur.

If server side code is generating the HTML then it should be server side. If client side is generating HTML then it should be client side.

In other words if server side is generating JSON to send to the client then server should be JSON encoding the data, but not prematurely HTML encode.


Is header('Location: ../page.php?param='.$param); vulnerable to unvalidated redirects? I have reviewed a web application built on PHP. It redirects to different pages this way:

$param = $_POST['param'];
header('Location: ../page.php?param='.$param);

Is it vulnerable to unvalidated redirects? In other words, can I redirect to another web site, manipulating the parameter param?

I don't think there is a risk for an open redirect vulnerability, since anything after the ? will be interpreted as query parameters and not a part of the path. But you should change your code anyway, since you do not make sure that the param is actually URL-encoded. Do this with urlencode():

header('Location: ../page.php?param='.urlencode($param));

However, if you use a version of PHP older than 5.1.2 you are vulnerable to header injection (see documentation). By sending a param that includes a newline an attacker could set multiple headers (or just set the location header again, overwriting the old value). Using urlencode() fixes that since \n would be encoded as %0A.

The whole construct could be unnecessary though - perhaps you can just check both $_POST and $_GET for param in page.php?


Protecting against Firewire DMA vulnerabilities in Linux I know there have been questions on this in the past but they all seem quite outdated, or not that specifically relevant.

I need to use a 1394(Firewire) connection, however am concerned with possible DMA vulnerabilities. From my understanding a firewire device could spoof the amount of memory it requires access to, such that all memory address can be potentially read from the system. Within Linux for example is there a way in which this space can be restricted, possibly using mmap?? Any ideas are greatly appreciated.

FireWire controllers of the type used in PCs (OHCI) have the ability to allow other FireWire devices to do remote DMA.
This feature must be enabled by the driver before it works.

The SBP-2 protocol is the only FireWire protocol that uses remote DMA; therefore, the Linux kernel enables remote DMA only for SBP-2 devices (i.e., hard disks and other storage devices), or any device that claims to be a SBP-2 device.

You can disable that driver by disabling it; write the line

blacklist firewire-sbp2

into any .conf file in /etc/modprobe.d, or disable CONFIG_FIREWIRE_SBP2 when compiling the kernel.

At the moment, the firewire-sbp2 driver relies on remote DMA for data transfers, so you have to choose between FireWire storage devices and protection from remote DMA attacks.
(It would be possible to implement those transfers in software, but this has not yet been implemented.)

The ability to read/write any memory is also useful for debugging from another system, so there is the option CONFIG_FIREWIRE_OHCI_REMOTE_DMA that enables remote DMA for any FireWire device.
However, this option is not enabled by default.


anti-replay attack for secure cookies? In the system that i'm working on, we are having some session cookies on the client side that we need to protect against the replay attack ! So I find the following paper http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf from this question Secure Session Cookies. I really like the way that they put things together. There is only one problem with this and that is the use of SSL session key (this is used for anti-replay purpose). I have some problems to get this parameter in my code (we use .Net framework and the server is running on IIS7.0). So I was wondering whether anyone has implemented this method for his/her system and whether you have a suggestion on replacing this parameter with another one.

Thanks

I have used mod_auth_tkt, which uses a very similar scheme.
I would suggest very careful consideration before use of the SSL session key: the user (application) session, TCP/HTTPS connections, and the SSL session ID and key are all distinct things. They don't necessarily have the same lifetime.
Further, reusing or repurposing cryptographic material is usually frowned upon (though I can't say that's there's definitely something wrong with its use in a HMAC, the problem is determining the opposite).
In the case of a conventional browser/web app, this sort of scheme can have immediately evident problems, e.g. when browser tabs don't share state.
What you have authenticated is a browser "state", tying it to anything else (SSL state or IP address) is fraught. Tying to SSL Session ID is more common (though has a history of MSIE problems). One of the better ways to achieve this is through the use of client certificates, not trivial to implement and manage of course.
See this for many more considerations: https://www.owasp.org/index.php/Session_Management
and (now complete) RFC 6896 Secure Cookie Sessions (draft linked to in the accepted answer to the question you link to) has a section devoted to replay issues.


How hiding the SMS number really works? I'm working in a web application and it has to include some send SMS feature; I'm planning to create an Android Application and use it to send SMS taking data from the server. The customer asked if the phone number can be hidden, I really couldn't answer the question; So that's pretty much my research this days. How hiding the phone number from a SMS works? Is it something with the provider or can the SMS number really be hidden or spoofed?

Greetings.

Usually this is done by the SMSC.  There are several online services that allow you to specify a "sender" value.  This could be a word, rather than a number.  Some companies, like banks do this (i.e: "Citibank", "HSBC", ...).

For example, using a popular SMS service such as Twilio, they allow you to set the sender ID, number or word.  Obviously with necessary restrictions.


Online security check via command line My scenario is that I have a VPS with Apache (mostly for development of my own projects) accessed via SSH; and I time to time I would like to do a quick check just to be sure that there's no potential flaw I would not be aware of.

Most of the time I'm behind evil firewalls so I can't simply do an n-map from another  (desktop) machine.

Now there are these services like nmap scan at online-domain-tools.com or GRC's ShieldsUp! that allow for such quick security checkup.

Nice. However:

they never offer scan of a third IP---only the very same IP that is requesting
the scan via the web interface (obviously because that could be easily abused)
since all (that I know) have web-based interface, it's quite complicated to use them
from SSH command line (unless you're a lynx/links freak); particularly, scans cannot
be easily scheduled or called from a test script

Is there an equivalent to these services that can be used for a single machine, via command line, or other terminal-friendly interface?

Edit: I'm starting to think I might be looking in the wrong direction.  Or that the service is yet to be offered ;)

But to make it clear, idea of such scenario is:

I make agreement (and pay) provider of this service, running on theirhost
I log in to myhost
Using a a CLI tool I instruct theirhost to scan me (which and how scans
 they run is their know-how)
Either directly or e.g. via e-mail, I receive results

Pay for another cheap VPS and install nmap, w3af, etc and any other tools there. Then you SSH in and run your tests. You could also schedule the tests to happen automatically and email the results.

This is not a pre-made service, but it does accomplish what you've asked for with a handful of tiny scripts, done more cheaply and with more control than a paid service.


What is the best way to respond to phishing emails sent from a government domain? In the past day or so, I've received two emails from different .gov addresses that purport to be from Intuit and encourage me to click on a link to "restore access to your QuickBooks account." They aren't pretending to be government addresses. If I click reply, the mail-to field says John.Doe@xxx.gov, just as the email states in the From section.

I have forwarded these emails to the FTC's recommended address for phishing scams, but I'd like to let the agencies involved know that they have compromised accounts. Is there an easy way to do that? I looked on the website of one agency, but there wasn't any contact that seemed right (Texas agriculture.gov).

Would emailing that person (at the compromised address) directly be useful? I don't want to spend all day on this, since I'm working. I just want to give someone a heads up. I was hoping there was a "report misused government email" contact box somewhere, but I can't find anything like that.

It is likely that the from header has been forged. I get emails from fake .govs quite often, mostly they end up in my spam filter. The hyperlink within is either unique, allowing tracking, or just delivers malware. Most of the time I just ignore these.

If you believe that the header is not forged then you can typically contact the agency by Googling their name and Webmaster or Contact Us or other such things. Do not use the phishing email, it is almost certainly fake.


Does HTTPS protect from session riding? In a typical session riding scenario, the attacker tricks the victim into sending an HTTP request to a web site they are already logged in to. For example, tricking victim to click on a link to trigger a CSRF attack. The browser includes the session cookie (and all other cookies for that site) in the HTTP request, thus attacker can execute any - possibly malicious - operation victim is authorized to perform.

HTTPS encrypts the whole packet, thus making it impossible to read the content, including headers and cookies. But does it protect the user from session riding attacks, or will the browser still include the cookies and use correct encryption automatically?

No because the browser dont change anything in the request when sending it over https (It will only encrypt it additionally). An attack with e.g. XSS will work exactly like it would work with http.

https only prevents from another type of attacks like man in the middle reading the session.


Why is additional_data empty in TLS 1.3? In draft 11 of TLS 1.3, additional_data is empty. Why?

First, thanks to StackzOfZtuff for digging through the various commits and finding out which are relevant.

From my understanding version and sequence where removed in draft 11 from additional_data since they were already protected by other means or no protection was needed in the first place. This is indicated by issue 278 which removes the version since it is not variable anymore. And in issue 318 the sequence number is removed given that the nonce is already included in AEAD input and the nonce is directly derived from the sequence number, which means that no addition  protection for the sequence number is needed. Since these were the only data contained in additional_data it was now empty.

In draft 25 additional_data where set to include the record layer header (i.e. type, legacy version and length) after a discussion in issue 1145 successfully argued that not only the encrypted data but also the record layer header need to be protected against modifications.


Nessus detect more open ports than nmap I scan my site via namp , I only see 3 ports open.

nmap -sV {ip}
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-25 09:42 EST
Nmap scan report for {ip}
Host is up (0.023s latency).
Not shown: 997 filtered ports
PORT    STATE  SERVICE VERSION
22/tcp  open   ssh     OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.13 (Ubuntu Linux; protocol 2.0)
80/tcp  open   http    nginx
443/tcp closed https
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.72 seconds

When I scan that same IP on Nessus, I see

Output

Port 2052/tcp was found to be open
Port    Hosts
2052 / tcp / www
www.my-site.com
Port 2053/tcp was found to be open
Port    Hosts
2053 / tcp / www
www.my-site.com
Port 2082/tcp was found to be open
Port    Hosts
2082 / tcp / www
www.my-site.com
Port 2083/tcp was found to be open
Port    Hosts
2083 / tcp / www
www.my-site.com
Port 2086/tcp was found to be open
Port    Hosts
2086 / tcp / www
www.my-site.com
Port 2087/tcp was found to be open
Port    Hosts
2087 / tcp / www
www.my-site.com
Port 2095/tcp was found to be open
Port    Hosts
2095 / tcp / www
www.my-site.com
Port 2096/tcp was found to be open
Port    Hosts
2096 / tcp / www
www.my-site.com
Port 443/tcp was found to be open
Port    Hosts
443 / tcp / www
www.my-site.com
Port 80/tcp was found to be open
Port    Hosts
80 / tcp / www
www.my-site.com
Port 8080/tcp was found to be open
Port    Hosts
8080 / tcp / www
www.my-site.com
Port 8443/tcp was found to be open
Port    Hosts
8443 / tcp / www
www.my-site.com
Port 8880/tcp was found to be open
Port    Hosts
8880 / tcp / www
www.my-site.com

Why they're different? Are they hidden ports?

What nmap commands should I use to same amount of port listed from Nessus ?

If you do not manually specify which ports to scan, nmap will scan the "top 1000" ports, supposedly representing the 1000 most common used ports at some point in time. Some of those ports you have look pretty non-standard, so I wouldn't be surprised if they weren't included in the "top 1000" list.

To specify which ports to scan, use nmap's -p option. It supports comma separated ports and/or ranges. To scan all TCP ports, use -p-, which is shorthand for -p0-65535.


Lost passphrase recovery for SSL Today is friday and I'm a desperate sysadmin. I issued a demand of certificate for an HTTPS server, and just received it after more than a long week of waiting, but while my request was processed I lost the passphrase that secured my private key.

Given that I have the private key and the public key jointly generated with the passphrase (that I knew by the time), could there be a clever way to recover the lost passphrase.

Thanks in advance.

You are out of luck.  A passphrase protected encrypted private key means you have to guess it and with the high entropy of a typical passphrase it will be very difficult.  Granted if you have a rough idea of what the passphrase is, you can write a script to try to brute force it (e.g., it was something like 'correct battery horse __' and subject to a dictionary attack).

This is the whole reason you put the passphrase on the private key.  (Granted I usually remove the passphrase from my SSL private keys on my server for convenience restarting apache/nginx; though leave them only root readable; figure if someone got to root they can install a keylogger and grab my passphrase anyhow).

EDIT: I should add in principle you could get at your private key if you break RSA (solve the problem of factoring the modulus N the product of two ~1024 bit prime numbers that's in the unencrypted public key; which would let you quickly regenerate the private key) or the passphrase encryption mechanism (typically DES3) to recover the private key.  However, if you could do either then anyone else could as well, which would not be a good situation.  Also, unless you have made fundamental breakthroughs in number theory, computer science, or developed a quantum computer it is prohibitively expensive to brute-force break RSA (like a million computers going for a million years would have under a 0.02% chance of breaking a 2048-bit RSA key).


For SameSite cookie with subdomains what are considered the same site? For the samesite cookie attribute I'm not clear on if I set a cookie with domain .example.com from sub.example.com with the samesite attribute, if it will be considered the same site as other.example.com.

Cookie behavior is different than CORS and I'm having trouble finding a resource that definitively clarifies this.

The 'Site' in SameSite refers to a the combination of second level domain mysite.com and top level domain mysite.com.

  This means that a requests from login.mysite.com to cdn.mysite.com
  would be considered a same-site request.

BUT... as you might imagine it does not end there. There is the Public Suffixes List which slightly changes this validation behavior.

Why? Well, because there are a number of sites where end users, and not the registrar or domain owner, control part of the domain (the sub-domain).
E.g. my-site.azurewebsites.net.

From a privacy and security perspective cookies scoped to my-site.azurewebsites.net should definitely not be sent to your-site.azurewebsites.net. And, since there is no algorithmic way for your browser to determine if a particular URL is of this type, the Public Suffixes List was created for browsers to change their same-site validation behavior. Hence, azurewebsites.net is listed on the Public Suffixes List.

  So, for sites on the Public Suffixes List a request from
  my-site.azurewebsites.net to your-site.azurewebsites.net would be
  considered cross-site.


Is it trivial to bypass IP blocking? There is a site with IP blocking.  When a client makes too many invalid attempts when guessing e.g. password, then their IP address becomes blocked.

I've heard about IP spoofing and similar attacks. Can an attacker spoof their IP address and continue their attempts to guess passwords?

If it matters, site uses HTTPS and HSTS.

Essentially it depends on the attacker and what resources they have available.  Ordinary home-users or attackers who aren't very dedicated might be deterred by source IP address blocking, but more advanced/determined attackers have a number of ways to get round this.

The obvious one is to use one of the wide range of proxy services available on the Internet.  This includes things like ToR and Anonymizer.com. Since one of the goals of these services is to mask the source IP address of the user, they will bypass the block until the attacker tries enough attempts with a given IP and gets blocked again.

As an interesting aside, the attacker could cause a partial DoS to your application by going round enough of these sites, as any of your other users who make use of those services will be blocked, once you block the IP addresses belonging to them.

On top of online services, the attacker could do things like use Wi-Fi hotspots or college/university networks to get access to more source IPs

So essentially this blocking would make things more awkward but wouldn't stop a determined attack.


(How) should I re-sign keys after transitioning to a new key? I recently transitioned to a new OpenPGP key, not because my old one was compromised, but because current best practices demand a longer key length.  I signed my old key with my new key, which goes some way towards preserving my place in the existing Web of Trust.

Are there any advantages or disadvantages to using the new key to re-sign the third-party keys I previously signed with the old key?  These third-party keys are still reachable from mine in the Web of Trust, by virtue of my having signed my old key with my new key, but wouldn't re-signing them make them slightly more reachable by others, by decreasing the overall path length?

If I do re-sign the keys, is it important to manually verify the fingerprints all over again, just in case the key has been lost or compromised?  Or is it acceptable to re-sign by default?

Are there any advantages or disadvantages to using the new key to re-sign the third-party keys I previously signed with the old key? These third-party keys are still reachable from mine in the Web of Trust, by virtue of my having signed my old key with my new key, but wouldn't re-signing them make them slightly more reachable by others, by decreasing the overall path length?

If you revoke your old key (after some time), you will lose a lot of connections into the web of trust if not signing other keys again.

Whether you want to sign them again or not in the end depends on your own policy. There is no ruling on this, the OpenPGP specification does not even mention specific rules on issuing certifications.

  If I do re-sign the keys, is it important to manually verify the fingerprints all over again, just in case the key has been lost or compromised? Or is it acceptable to re-sign by default?

By looking on the fingerprints, you will not be able to decide whether a key has been lost of compromised: you'd have to get in touch with the key holder again. Whether you want to do this additional effort is up to you. GnuPG will restrain from signing revoked keys, anyway (be sure to update them before signing). On the other hand, issuing a new certification might be considered a new statement "I am sure about the keyholder's identity" and is connected with a timestamp: are you still sure about how you verified the identity, which user IDs you selected for signing (you can look this up) and why (this will get more difficult)?

I would not care about verifying fingerprints, but instead using the fingerprints to reference other's keys directly. Such a list can be derived by a simple script and can be directly used to sign keys, caff might provide an easier interface for this.

Personally, I'd only care about signing people I know well and care about.


Is there any security reason to prefer local IP address over zeroconf ".local" domain name? I have some Linux servers on my local network. When I connect to them via SSH or VNC, I can either use the local 10.0.x.x IP address my router assigns, or I can use the zeroconf "hostname.local" address that they broadcast themselves.

The zeroconf address just seems too convenient.

Are there any security concerns specifically related to relying on zeroconf domain names that would not be an issue with local IPs?

SSH stores host keys. If the host key is not matching what is expected for a given name or IP, you will at the very least get a warning with all SSH implementations I've tried. OpenSSH will by default reject the connection, and you will have to manually run a command to remove the offending key.

VNC does not have this protection, but you can wrap it inside SSH to achieve same protection as SSH offers against MiTM.


How does one take advantage of unencrypted traffic? Let's assume an ecommerce site works over HTTP, rather than HTTPS.
What are the practical dangers here? How could an attacker exploit this?
Whenever I read about dangers of unencrypted traffic, it is somehow magically assumed that the attacker has managed to somehow slip into a point between me and the endpoint (establish a MITM).
I get that the owner of the Wi-Fi hotspot could be snatching my data. Or it could be some malicious worker at my ISP.
However, assuming I'm sitting behind my own router and I trust my ISP, how could one set up a MITM attack that'd allow to exploit the lack of encryption?

You can trust your ISP, but your data will not pass through just your ISP's routers. On a simple level, the internet works by passing data from one router to another, repeatedly moving each packet closer to its destination, until it is hopefully delivered. This means that your connection passes through several routers before finally reaching the site you are connecting to.
Now, as an example, right now, there are 10 routers sitting between me and stackexchange.com. Of these, apparently only the first two or three belong to my ISP. The rest either belong to some internet backbone provider, the server's ISP, or any other upstream ISP that exists between my ISP and the server's ISP. So now, instead of having to trust one ISP, you have to trust at least two ISPs and the internet backbone providers. Now that's a lot of people to trust. If any one of these has a rogue employee with access to install malware on the routers, or any of these routers are misconfigured or using outdated firmware with known vulnerabilities, an attacker can perform a Man in the Middle attack and harvest your credit card details, passwords, PII etc. as well as inject ads and/or malware and perform any other malicious action they can think of.
And that doesn't even take into account state sponsored attackers and mass surveillance. A  state sponsored actor that is interested in getting access to plaintext HTTP traffic doesn't even require a rogue employee or exploitable router vulnerability. They can serve the ISP a subpoena or they can silently tap right into the fiber-optic cables. If the traffic they are targeting doesn't pass through their jurisdiction, they have the resources to perform attacks like BGP hijacking to redirect the traffic through their own jurisdiction.*

*In at least one incident, a non-state sponsored attacker also managed to perform this by hacking an ISP


Is it safe to have the salt equal to IV? If I'm using AES-256 CBC to encrypt, getting the 32 byte key using multiple iterations of the PBKDF2 function with a 16 byte salt, is it safe for me to let IV be equal to the salt?

(Edit: The salt is randomly generated each time. This would of course make the IV also randomly generated each time.)

How much security is lost when doing this? If I do this, the advantage is that I only will have to store the salt in the final encrypted file, not both the salt and IV (making the file 16 byte smaller!)

There is no known issue with reusing the salt used in PBKDF2 for the IV of CBC encryption, and it would be mildly surprising if it did have an impact because the salt enters as input to hash functions, and the output is used as key for the block cipher. Thus, there are "two layers" between the salt and the IV. However, surprises do happen sometimes. Reuse of any data element for two roles is, as a basic rule, potentially dangerous.

Since PBKDF2 is a Key Derivation Function which can produce an output of arbitrary length, it seems safer to simply make it generate the key and the IV. That's what is usually done in these matters.

Alternatively, if the key obtained from the password and salt will be used for only one file ever, then you could use a fixed, conventional IV (trouble with IV in CBC begins at the second usage of the key, so it tolerates an all-zero IV if and only if the key is used only once). It would still be better to replace CBC with an Authenticated Encryption mode like EAX or GCM, which has fewer constraints on IV (with EAX or GCM, it is "obvious" that a conventional IV is not a problem, as long as the key is used once) and will give you integrity on top of confidentiality.


Is it dangerous to keep permissions at 666 to member file on SELinux? I just installed SELinux. I read a lot of tutorials but I am not very comfortable with SELinux.

On CentOS help page , I can see that some files in
/selinux/ are writable by other user : https://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-selinux.html#s2-SELinux-files-selinux like member file.

The first thing I said to myself is it's dangerous because someone who not allowed which can modify theses files. But I tried, and I can't.

I think it's because the labels are system_u:object_r:security_t:s0 and when I tape id -Z, the result is unconfined_u:unconfined_u:unconfined_u:s0-s0:c0.c1023

Is it because I am on unconfined_u context that I can't write in this file ? Is it not dangerous to keep with 666 permission ?
If that I said is incorrect, can you explain me why ?
Thanks.

SELinux contexts come in addition to permissions and ownership. In order to access a file, a process needs to have the privileges given by ownership and to pass the checks made by SELinux. To take an extreme example, it's possible to create a root account (user ID 0) on a machine where SELinux confines this account so much that it can't make use of root privileges for anything. A file with permissions 666 but an SELinux context that prevents access is perfectly safe.

This doesn't mean that relying solely on SELinux to control access is risk-free. It's perfectly fine as long as the file isn't changed, but if the file is edited, or copied, or backed up, or otherwise affected by a tool that doesn't support SELinux then the SELinux context could be lost. Furthermore SELinux is notoriously hard to configure correctly; permissions are a lot easier to understand and audit. You should treat it as a second line of defense.

In the case of /selinux, that's a special filesystem which exposes information and controls related to the SELinux configuration. It's designed and populated by the people who make SELinux, so the risk that it's misconfigured is very low. It isn't going to be backed up or edited. So the risks of SELinux lack of support or misconfiguration do not apply. /selinux is part of how SELinux works and is not dangerous.


any information about en.quiente.info who has visited your account website I ran across this site http://en.quiente.info, my friends tried it and they say it worked for them. It asks for most of the privileges on Facebook even sending messages on behalf of you.

Any one has an explanation for his. I didn't try it personally I'm afraid of losing my account.

The site works (most likely- I haven't visited it either) by requesting YOUR permissions to see and record what YOU do. It then looks in its database to see if your friends also use it- if they do, it can show you what THEY have done.

It can't show you what anyone who is not a member of their site is doing, which is why it is so insistent that you get your pals to join.

It should unsurprising to anyone that using it is a terrible idea, and will turn predatory if not malicious at some point, as others have mentioned.


What is a simple and secure method to transfer virtual assets? Consider a MMORPG where users own virtual assets like magical swords or rings that can be used by the player. This system needs a safe method for transferring assets from Alice to Bob.

One requirement that increases the complexity is the fact that it should allow Alice to transfer an item to Bob before Bob registers himself. This is part of a marketing campaign to attract users into the game.

In one solution, Alice initiates the transfer by typing Bob's email or phone number. This is subject to human error. In order to prevent Alice from accidentally transferring the item to a stranger, we want Alice to validate the transfer by forcing Bob to send some information that only Alice knows.

The current protocol is as follows:

Alice initiates the transfer by specifying Bob's contact (email or phone) and a question that Bob needs to answer. Alice does not tell the answer (i.e. the game cannot possibly leak this).
The system uses Bob's contact to send a link. When Bob clicks on it, he is asked to login or register himself. This action is associated with the transfer.
After Bob is properly logged in, he is presented with Alice's question.
Bob types the answer and submits.
When Alice logs in, she receives the answer, validates and the transfer is finished. Now Bob can use the item.
In case Bob fails to finish this process in 7 days, Alice gets the item back.

The managers think this entire process is too complex for the average user.

One change is to allow Alice to specify the answer along with the question. At least Bob is be able to immediately use the item (i.e. without waiting for Alice first). However this also allows Alice to complain that we leaked the answer and someone else got the item.

What are the existing methods for transferring assets that can be considered? Again, the main requirement is to allow Alice to initiate the transfer before Bob is registered...

I would agree with the managers that the process is way to complex. I think you could make this fairly straight forward by mimicking the process used to send e-gift cards.

Alice hands over the item to (your MMO's recruiting NPC) and gives Bob's email address.
Bob receives an email with a 12 digit alpha numeric code that can be typed in to the web form used to register.
When Bob logs in for the first time the item will appear in his inventory or bank.

You can even go 1 step further and have a direct link in the email when clicked that will automatically associate Bob's registration with the item.


Determining httpd PHP Scripts with Auditd Background
I have an issue on my server where some hole is allowing malicious PHP files to be written to any world-writable directories beneath the web root. It is not currently causing any harm, as I have all these directories blocked from serving php scripts (or anything else unless images/videos for some of them), and get an email notice as soon as anything is created in them, but I obviously want to get it fixed.
I have taken various measures, such as ensuring the Joomla and Wordpress installations on the server are up to date, but still it continues. There is a client site on the server running a fairly old version of an eCommerce system, which I suspect may be the culprit.
Question
So I have set up auditd to monitor all of these world-writable directories, and await the problem occurring again to gather some logs, but I already have some log entries to look at from normal activity that has occurred.
It is as I suspected, and of course when a PHP script writes to a file all auditd shows for the exe is /usr/sbin/httpd. See sample output below. It is potentially possible to get an idea of which site the problem is coming from based on the CWD, but that could be changed and is not reliable. Also knowing the specific script would be useful.
So I am wondering, is it possible to have auditd log the script name (edit: or perhaps the call stack) that is generating the action through /usr/sbin/httpd, or anything close to that information?

time->Wed Nov 30 14:36:30 2016
type=PATH msg=audit(1480516590.911:180239): item=1 name="/home/web/www.example.com/html/cache/example.php" inode=539842913 dev=08:05 mode=0100644 ouid=48 ogid=48 rdev=00:00 objtype=CREATE
type=PATH msg=audit(1480516590.911:180239): item=0 name="/home/web/www.example.com/html/cache/" inode=539833631 dev=08:05 mode=040777 ouid=634 ogid=634 rdev=00:00 objtype=PARENT
type=CWD msg=audit(1480516590.911:180239):  cwd="/home/web/www.example.com/html"
type=SYSCALL msg=audit(1480516590.911:180239): arch=c000003e syscall=2 success=yes exit=36 a0=7f9baf272550 a1=241 a2=1b6 a3=9 items=2 ppid=26483 pid=30957 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" key="write_to_open_web_directories"

auditd cannot perform a stack trace or gain other information because it's only invoked on system calls or file access.  The stack trace is only accessible from userspace, and would require unwinding the stack, which would incur significant overhead.

As mentioned in the comments, you can add %P to the access log config to get PIDs for correlation with auditd, or log the full requests from mod_security.

You could also modify mod_php or use an LD_PRELOAD to add information to relevant requests on file open.


What benefits are there for security architecture being a separate discipline to enterprise architecture? Had this question at Owasp Scotland this evening, and didn't get useful answers.

Is there too much specialisation in security now which means that enterprise architects can't know enough to delivery security as part of their day job?

My first observation is that security is everybody's responsibility.  No one person is going to be able to police an entire organization's codebase.  Security design and enterprise design are inherently different in purpose and goal, but the two should interact closely for best result.  An enterprise architect's goal is to design a system that meets business needs and represents business processes accurately and come up with a consistent pattern for implementing such functionality.  A security architects goal is to design a pattern of security and provide a consistent pattern for it's implementation and enforcement.

In a large environment, the mere scale of these two tasks might merit different people working on them and there could be a slight gain in relation to separation of responsibility between the business process and the security process, but in general I don't see any strong reason why someone with a cross over skill set couldn't do both.  (I say this as an enterprise software architect with a background in security design.)