Automatic harvesting of hacked hosts and reporting to domain/site admin With so many internet attacks out there, I just think it would be convenient (and quicker and wise) if there is a way to automatically harvest the hacked hosts that are used to launch internet attacks/probes. For example a SSH host could install DenyHosts and/or implement hosts.deny. From failed authentication data we can collect all the IP addresses of those hosts, and automatically (or semi-automatically, if that would be better) report to the site admins that their machines have been hacked. Is there any tool or online service like that? This would allow hacked machines to be squashed in a speedy manner.

This would be analogous to spamcop.net for spams. But now there are many more hacks and attempts, it does not make sense to mail site admins manually.

You may want to check out http://www.dshield.org/

They have been providing this type of service for quite sometime. You can integrate with firewalls, tcp wrappers or other methods.

I for one don't find this approach too useful for security.  I find anomaly and behavior based methods provide better results with less fuss.


Force https, complex implementation I have a website running on a dedicated server (single IP) on apache.
Multiple domains are pointed to the website . For ex: sub.abc.com, sub.bcdaf.com

I have now purchased a single SSL certificate for one of the domains (sub.abc.com).
Only SSL only works when user accesses https://sub.abc.com

I want to force users to https when they access http.
And by default, when they access sub.abc.com, it should go to https://sub.abc.com .
How can i do this via htaccess?

Please note that the https only works for sub.abc.com and should forcing users should happen only for sub.abc.com

redirect as @Terry mentioned is ok, but will not work if users use bookmarks and you want to make them available also in HTTPS:

dont forget to use HSTS-Headers
Solution using .htaccess only (untested) (see apache-wiki)

you can skip the %{HTTP_HOST} - condition if you use a
<virtualhost> - config for each virtual host
and no catchall/regex-servernames

--- first solution
RewriteCond %{HTTP_HOST} sub\.abc\.com
RewriteCond %{HTTPS} !=on
RewriteRule ^/(.*)$ https://sub.abc.com/$1 [r=301,L]

--- 2nd solution
RewriteCond %{HTTP_HOST} sub\.abc\.com
RewriteCond %{SERVER_PORT} ^443
RewriteRule ^/(.*)$ https://sub.abc.com/$1 [r=301,L]

Solution using Rewrite-Rule and with working deep links / server-config (prefered by official docs):

<virtualhost :80>
    ServerName sub.abcd.com
    RewriteRule ^/(.*) https://sub.abcd.com/$1     [R=301,L]

</virtualhost>

<virtualhost :443>
     ServerName sub.abcd.com
     Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</virtualhost>


Do users of non-latin character languages suffer from spyware and trojans? Do Chinese, Japanese, other languages that can't be represented in ASCII get their passwords stolen?  I figure there can't be some sort of bruteforce attack software for them, right?  Their characters are so different the the usual ASCII or us keyboards.

Let's start with looking at keyboards and language sets to understand they work. First up, we have ASCII which is how you're used to characters being saved. ASCII is an encoding, which maps individual characters to some binary combination. In modern computing, we're used to the idea of a byte being 8 bits long, but various hardware implementations (especially decades ago) have used other sizes.

But for now, let's settle with the idea that the world uses 8-bit bytes. English is easy because you can easily fit all predominant punctuation and symbols in 7 bits of space. Yet other latin-character languages such as French have important yet missing symbols in this space. To handle that, other representations besides ASCII such as ISO 8859-15 (Latin-9) come into play. Consider that if you used the ¾ symbol when writing with Latin-1 encoding, it would show up as Ÿ in Latin-9

Nothing really restricts one to using just a byte for defining a symbol, though. In fact, you can see the difference in my example above (a 3/4 symbol and a Y with a diaeresis over it) if you have Unicode properly working. Unicode is able to display this by using longer symbol tables in the form of UTF-16 or UTF-32. In that case, a symbol might be 2 or 4 bytes long, but have one meaning.

With Asian languages where symbols are more concept-based rather than letter based, this doesn't work as well for space, and so Unicode is particularly useful. In either case, though, the encodings really only matter for the human element. Once you send these down the wire, the computer isn't comparing to see whether you entered ¾ or Ÿ, it's checking to see if the binary value is 10111110. Thus, it's only the display that matters. That same value goes down the wire regardless of who wrote it, and indeed somebody in France will probably see a different appearance than I will hear and would press different keys on their keyboard to create it. In fact, for each language there are all sorts of keyboard layouts.

So, since everything is just a byte, malware works the same regardless. As far as trojans go, they have to be written to the language of the user they're targeting (remember, a trojan pretends to be something useful), but they function just the same.

As for brute-forcing, the time is a factor of the number of symbols tried. So one can brute-force (especially via dictionary) just as well in any encoding if all binary space is used, and much faster if you know the dictionary of valid entries to try.


Security without TLS certificates after getting an answer to Security over multi-streaming such as SCTP i have found that i do not have the capacity to give a public key or certificate to the other end securely (to be sure MitM cannot substitute one and that no-one can see it).   i do have the capacity to send a 256-bit key securely.  both ends are under the same admin but there is no opportunity to set up a key or cert on either end besides the mentioned limited capacity (because it is a cloud image launched when needed).  "shared secret" seems to be the wrong terminology as all uses i see for this refer to sharing between different parties (the "sharing" is just between these two ends).  this is also a symmetric connection once established ... such as a VPN (it will be used as a VPN and it will use SCTP). my question is: how can i be sure this is secure?  security is hard.

i have used openssl before in this script and am looking to use its C-layer API for this project.

There is a variation of TLS that uses a Pre-Shared Key instead of certificates, called TLS-PSK. This basically works the same way as usual TLS except the session key is generated in a different way. You should take a look at this.


Is it secure to use HttpSessionState.Session to store Identifying Information I am writing an ASP.NET web app and am wondering if there is anything that is insecure to store in HttpSessionState.Session?

More specifically, is it bad practice to store such information as UserID, or security permissions in the Session? My concern is that this information can be spoofed by a user/hacker to give themselves permissions afforded to another user.

Objects stored in a HttpSessionState session are stored on the server-side.  They can only be accessed by your application code, not by the client (the browser) or the user using the browser like a client-side storage mechanism (like cookies) might allow.

So, there is no direct way for a user to tamper with or modify the value of session objects.   The only way a malicious user can abuse session state would be to steal an entire sesssion, which is known as a session hijacking attack, or force a victim user to use a specific session, which is known as a session fixation attack.  This is accomplished by taking the value of a cookie that is sent to the browser that identifies the session a user is associated with, so that it can be accessed on subsequent requests.   If a malicious user can steal another user's session cookie/id or force another use to use the attackers previously established session id, (often relying on separate cross-site-scripting attacks to accomplish) the attacker than then either impersonate the victim, or get the victim to perform an action on the attacker's behalf.

Even in these cases, however, the attacker is limited to the transfer of the session in its entirety.  He or she still has no control over the values of the properties stored server-side for the session.


Are there any security risks to accepting HTTP/0.9 style GET requests? (e.g. "GET /\r\n") I'm writing a web server for fun, and I'm first adding support for HTTP/1.0.  The primary reference I'm using is RFC 1945 => Hypertext Transfer Protocol -- HTTP/1.0.

In section 5.1 of the RFC, I learned that HTTP requests can be a single line, a GET method and a URI (e.g. GET /\r\n).  The RFC refers to this as a Simple-Request.

In modern HTTP servers, are there any security risks associated with accepting, and responding to, a Simple-Request?  If yes, what are the risks?

You could in theory accept any junk. But how do you want to respond to it? If the client sends HTTP 0.9 then you should not respond with HTTP/1.0 or HTTP/1.1 since such a client will likely not understand it. HTTP 0.9 means specifically no HTTP header in the response. This means lack of semantics to express things like Content-Type or Cookie. Given that most applications today relies on providing such information you also need to find ways to express the necessary semantics with such old clients which makes everything more complex.

Apart from that - HTTP is a complex enough protocol already (if properly implemented). Given that HTTP 0.9 is obsolete for more than 20 years and that there is no current and relevant client out there which still needs HTTP 0.9, you essentially add code which will never be needed for a practical purpose. This means that this code will be less tested than the rest and that the chance of critical bugs in this part of the code is much higher than in the rest. And while no relevant client will actually use HTTP 0.9 one can write a client which will do and which might make use of critical bugs inside this poorly tested code path.

In short: don't implement anything which is not needed. This way the code base is smaller and easier to test which results in more robust code. Anything which is not used in practice will result in rotten code which has no practical relevance except to cause trouble, for example by being a potential attack vector.


Is it theoretically possible to hack printer using scanner tray? If the scanner tray is considered as an interface, and it accepts input (basically it is its main functionality), could it be hacked using malicious code written on a piece of paper?

The answer entirely depends on implementation of scanning process in the printer. Modern printers are in essence computers and they are much more powerful than their predecessors from earlier days.

So, the question boils down to "is it possible to hack a computer by using an image"?

The answer is yes, because creating exploit-free software is almost impossible as described in the answers here: Is exploit-free software possible?

Image handling libraries happen to have vulnerabilities. An attacker could entice a user to open specifically crafted image which would exploit a vulnerability on victim's computer, and therefore affect it in some way.

So, if printer's scanning process involves some sort of processing of scanned images, and its software contains bugs, then we can assume this vulnerability can be exploited by a knowledgeable attacker.

  could it be hacked using malicious code written on a piece of paper?

The printer won't execute code written on a piece of paper. However, there exists probability that printer's software used for processing of scanned images contains bugs that make printer misbehave if it encounters a certain image.

The attack surface depends on how much processing the printer does with the documents that are being scanned.

The result of this is hard to tell. It depends a lot on the printer and its software, its capabilities.


How to deal with this fundamental problem with the advice: "Don't trust obscure PHP libraries that nobody uses!"? Frequently, I'd say in virtually every case, there is only one PHP library for any particular problem. (I don't count obsolete, abandoned, trash ones.)

Therefore, it's never a "choice" by me to use it. I have to either use it or nothing.

For this simple reason, the sound-sounding safety advice to "not use obscure libraries not promoted or used by lots of people and major corporations" is rarely applicable, because there just aren't any alternatives to pick from!

And this is for PHP -- one of the most popular/biggest/most used current programming languages on the planet. Imagine if I were using some far less popular language; I'd never find a library to do anything!

It seems like this advice only works in theory. In reality, there's very little, if any, choice between libraries and even languages unless you are going to do everything on your own, from scratch. (Or possibly if you can pay money, which I cannot, and thus I've never even considered any potentially existing paid alternatives.)

The reason I ask this question is that I'm always given it as one of the main tips for how to stay secure and not get malware through compromised/evil PHP libraries. However, when there's just one thing to pick, for example "MailMimeParser", which nearly always seems to be the case (with any "alternatives" having major show-stoppers such as being dead or just not working as advertised), what else can I do?

You say that you don't have a choice, but that's not true. You could write all the code you need yourself. Or you could pay a trusted professional to write the code for you. Or you could could pay a security firm to audit the code before you use it. Or you could accept the risk, and implement other security controls to mitigate the risks. For example, if you are afraid that some code might be vulnerable to SQL injection, you could set up a WAF (Web Application Firewall) in front of it.

Security has a cost: time, resources, expertise, money. There's no free lunch. If you can't afford it, you'd have to either avoid the problem (rethink your project), or delegate it (somebody else will deal with it), or mitigate it (for example with defense in depth) or just accept the risk that you might get hacked.

Personally, in your case, when you have to deal with code that is not widely used, if the library is not too big I'd try to read the code, at least to check if there's any "code smell". Even if you don't check all the logic, it's easy to check if there are enough comments, if they make sense, if the code is clean and understandable, if certain functions are used according to best practices, if there are checks on the input data, etc. The risk of code used by only a few people and maintained by only a few developers is also that it might stop being maintained, or maintenance turns out to be too slow anyway, so at the end of the day you might be forced to read and understand the code anyway, to fix your application.Then if possible I'd also try to implement something for defense in depth, although configuring a WAF correctly might not be easy, if you really want it to be effective and at the same time avoid breaking your application because of false positives.


What CVE identifier will follow after CVE-2012-9999? I am writing an application which uses CVE identifiers to cross-reference vulnerabilities. I would like to make it compatible with future CVE identifiers.

If it happens that there are more than 9999 CVE identifiers in a year, what number will follow after 9999?

For example what will be the identifier after CVE-2012-9999? Will it be CVE-2012-10000 or something else?

The highest CVE number in 2011 seems to be CVE-2011-5096 thus it is just a matter of time when this becomes a real issue.

I have tried to find this out at https://cve.mitre.org/ but I can only find the following:

  CVE entries and candidates are of the form CVE-YYYY-XXXX where YYYY
  is a year, and XXXX is a number.

That does not really help.

The Common Vulnerability and Exposures system is maintained by Mitre.  The Mitre corporation manages the CVE list and serves as an organizer for the CVE community.

At the start of the year Mitre will allocate blocks of CVE numbers to various CVE Numbering authorities out of the full 9998 available (0001-9999).    As a result,  all CVE numbers issued to an authority within a given year will fall within a range.  For example in 2012 all CVE numbers issued to Apple products fall within the CVE-2012-3600 range.  Mitre will leave unallocated space in order to issue new CVE numbers if a CVE authority were to exhaust their supply.

So what about your question?  What if they have 10,000 CVE numbers issued in one year?   Well the most ever issued was 6,608 in 2006.  So that was close,  but since 2006 there has been an unsettling rate of decline so it doesn't look like we will ever issue 10,000 CVE numbers in one year.  If we were,  I suspect that we will have CVE-2012-10000.  They would do this because its regular,  the only reason why they have the four digit number scheme is to allow for pre-allocation to CVE authorities.

From my experience emailing Mitre is usually the best way to obtain CVE numbers.   They treat you with respect and have the option to preserve your anonymity.  Mitre will work with vendors to make sure the issues are fixed and issue a CVE to the public when a fix is available.


AES Key Management / How To Swap Encryption Key I'm currently using AES 256 for the encryption of my web application and the security policy context specifies that the encryption key must be replaced once every few months.

When that happens what handling needs to be done in particular? What I read online suggests that I'll need to decrypt the existing encrypted data with the old key and then encrypt the decrypted again with the new key. This approach may not be an ideal solution for me as my web application may have to deal with big amount of data and the process above would take quite some time. Is there a better solution around this?

Thanks

Encryption keys can have a cryptoperiod after which those keys shouldn't continue to be used for encryption. This may be due to security policies, due to an individual who knows a key component leaving the business, due to suspicion of an encryption key compromise etc.

Often, a business will use an encryption key (let's call this keyA) for encryption for X period of time. Following that period of time a new encryption key (let's call this keyB) will be generated and used for encryption.  The encrypted data will be stored with a reference to the key it was encrypted with so the application knows what key to use for decryption. Using our naming above, keyA could be considered invalid for the encryption of new data but could be used for the decryption of data encrypted using that key. KeyB may currently be valid for both encrypting and decrypting data.

As your data is probably stored according to defined data retention periods, once legacy data is purged, older keys may also be removed as they are no longer required for the decryption of data.

Per your post, decrypting and re-encrypting large volumes of data can be time consuming and process expensive.


IP packet generate manually? I have heard that we can create ip-packets by our own and send it to a network or a  host.
How this Can Be Done ?Please Explain step by step??

PCap library can be used not only to sniff packets, but also to construct and send packets.

  In the field of computer network administration, pcap (packet capture)
  consists of an application programming interface (API) for capturing
  network traffic. Unix-like systems implement pcap in the libpcap
  library; Windows uses a port of libpcap known as WinPcap.

There is a good example:

  The simplest way to send a packet is shown in the following code
  snippet. After opening an adapter, pcap_sendpacket() is called to send
  a hand-crafted packet. pcap_sendpacket() takes as arguments a buffer
  containing the data to send, the length of the buffer and the adapter
  that will send it. Notice that the buffer is sent to the net as is,
  without any manipulation. This means that the application has to
  create the correct protocol headers in order to send something
  meaningful.

Please note you have the full control. You can change Ethernet frame as well.

#include <stdlib.h>
#include <stdio.h>

#include <pcap.h>

void main(int argc, char **argv)
{
pcap_t *fp;
char errbuf[PCAP_ERRBUF_SIZE];
u_char packet[100];
int i;

    /* Check the validity of the command line */
    if (argc != 2)
    {
        printf("usage: %s interface (e.g. 'rpcap://eth0')", argv[0]);
        return;
    }

    /* Open the output device */
    if ( (fp= pcap_open(argv[1],            // name of the device
                        100,                // portion of the packet to capture (only the first 100 bytes)
                        PCAP_OPENFLAG_PROMISCUOUS,  // promiscuous mode
                        1000,               // read timeout
                        NULL,               // authentication on the remote machine
                        errbuf              // error buffer
                        ) ) == NULL)
    {
        fprintf(stderr,"\nUnable to open the adapter. %s is not supported by WinPcap\n", argv[1]);
        return;
    }

    /* Supposing to be on ethernet, set mac destination to 1:1:1:1:1:1 */
    packet[0]=1;
    packet[1]=1;
    packet[2]=1;
    packet[3]=1;
    packet[4]=1;
    packet[5]=1;

    /* set mac source to 2:2:2:2:2:2 */
    packet[6]=2;
    packet[7]=2;
    packet[8]=2;
    packet[9]=2;
    packet[10]=2;
    packet[11]=2;

    /* Fill the rest of the packet */
    for(i=12;i<100;i++)
    {
        packet[i]=i%256;
    }

    /* Send down the packet */
    if (pcap_sendpacket(fp, packet, 100 /* size */) != 0)
    {
        fprintf(stderr,"\nError sending the packet: \n", pcap_geterr(fp));
        return;
    }

    return;
}

Update

There are several wrappers available:

http://sourceforge.net/projects/jpcap/
http://jnetpcap.com/
https://code.google.com/p/sjpcap/


ESNI (Encrypted Server Network Identification) with HTTP CONNECT (HTTP Proxy) Regarding ESNI RFC (https://tools.ietf.org/html/draft-ietf-tls-esni-02) it copes with many possible security vulnerabilities. However I'm interested how is it supposed to prevent confidential information leakage (SNI) in case of HTTP Proxy is used (or forced to be used)?

HTTP CONNECT request sends domain's FQDN in plaintext before any connection is tunneled.

I know proxy is another layer not so related to ESNI itself but I think it should be considered as a possible weakness.

Am I missing something here?

(btw please someone add new tags "esni", "sni" and "tls-1.3" to this question - don't have reputation for that, thanks)

The goal of ESNI is deny observability of the target domain when only passive sniffing of the traffic is done. This targets primarily deep packet inspection at the level of ISP which might like to create profiles of users or restrict/shape some traffic to some targets for their own gain or because laws require it.

This does not prevent the visibility of the target domain in the CONNECT request. But a CONNECT request is only issued by the browser if a proxy is explicitly configured in the browser. This need to be done by a person controlling the computer and is often pushed via company wide policies. Explicit proxies are usually used only within the company (or home) network - which means out of reach of the ISP. And traffic visibility and regulation inside these privately owned networks is commonly (more or less) accepted as necessity.


Will SHA1 of Email Addresses Always be Unique? We want to store data about a person without storing their email address, but we want to latter connect that person with their data upon them supplying their email address.

Storing a SHA1 of their (lowercased) email address will accomplish that, but is it possible that two different email addresses would result in the same SHA1?  If so, what's the probability?

Cesl

The chance of this happening by accident is negligible. It's approximately n2/2159 when you have n email addresses. For example if you have a billion emails, the chance is 2-99 or 10-30.

So assuming that it doesn't happen by accident is a pretty safe bet.
Somebody will be able to craft two email addresses that have the same hash, but he won't be able to craft an email that matches the hash of another person that's not identical to that person's email.

Or as a cryptographer would say, collision attacks against SHA-1 are feasible, but pre-images are not.

But collision attacks seem irrelevant for your application. Since I don't see how an attacker would take advantage of owning two emails with a matching hash.
Guessing the email and confirming it against a hash is possible. The main problem here is that SHA-1 is fast.

I ran such an attack against the MD5 gravatar hashes stackoverflow publishes, and recovered around 28%. Somebody who puts in more effort will probably be able to recover a bit more.

My recommendation is to use an expensive hashing construction such as PBKDF-2-HMAC-SHA-2 with a per-application salt.


Effectiveness of Euler's totient function and Carmichael's totient function in generating the public key in RSA encryption I'm a high school student taking IB and for my EE on Maths, I'm comparing the effectiveness of Euler's totient function and Carmichael's totient function in generating the public key in RSA encryption.

In order to compare the 'effectiveness' of these functions, I will firstly compare how fast they can generate the public key and then secondly, compare the security of the generated key. For the 'fastness' part I will use time complexity. But I have no idea how to compare their security. Can anyone help me figure this out? Maybe an algorithm that is often used to test the security of an encryption key? Or should I just write a code to execute encryption keys made using either Euler's or Carmichael's totient function and see how long it takes to decrypt each key?

Thanks!

Not strictly an answer because I reject the question, but too long for comments. Related but not quite (cross)dupe:
https://crypto.stackexchange.com/questions/29591/lcm-versus-phi-in-rsa
https://crypto.stackexchange.com/questions/33676/why-do-we-need-eulers-totient-function-varphin-in-rsa

Although mathematically RSA can use any d and e that are inverses modulo either Euler's totient (commonly phi) or Carmichael's (commonly lambda), in practice we use a predetermined small e (commonly 3 or 65537, the latter being the Fermat prime F4) and compute d as the inverse of that. Thus which mod is used for the inverse has no effect on the public exponent and public key, only the private exponent and naive private key. Since the phi inverse is almost always larger than the lambda inverse, naive decryption using the former would be slightly slower. But in practice we don't use naive decryption, we use the Chinese Remainder Theorem method with d mod p-1 and d mod q-1, and those are the same no matter which way d was computed, so it makes no difference to either time or security of encryption or decryption. It may make a tiny difference to time of key generation, but key generation is normally done only rarely, and is very heavily dominated by prime testing, or prime building for provable methods.

And if it did make a difference to security you couldn't determine that by measuring the time or even computing the time complexity.

PS: at least in US, we normally use 'effective' to describe or measure only that something works correctly, and 'efficient' to describe or measure that it is fast (uses little time) and/or uses little of other relevant resources such as memory, bandwidth, power, etc.


Why using "state" variable in OAuth 2 I am building an application that is integrated with a 3rd party service provider and uses OAuth 2 to obtain permission from other users using the service to access their account information. Based on the documentation, the implementation process is:

A user clicks a frontend element of my application, which makes a call to my backend.

Before my backend sends the link to the user to redirect him to the 3rd party application's authentication page, I need to create a cookie to store a randomly generated md5 string as "state" at my backend, and the "state" variable is included in the URL link.

After the user uses the link to log into his account and grant my application the permission, a response containing authorization code is sent to my backend.

My backend first checks whether the "state" in cookie matches the "state" in the response. If it does, then my backend will use the authorization code to make a call to the 3rd party's backend to obtain a token.

The documentation states that a "state" variable is needed to protect against cross-site request forgery (CSRF). However, I cannot think of a way how CSRF can happen during this process. CSRF means that a malicious hacker tricks an authenticated user to send an unintended request to the application backend, which is often done by injecting html and javascript into the application's web page. However, in the process mentioned above, after the user is authenticated by the 3rd party, he is completely in the realm of the 3rd party application, which can be assumed to be safe from the 3rd party's point of view. Even if a CSRF does occur, I do not understand how the "state" variable can detect and prevent this.
In short, my questions is: How can a CSRF take place in the process mentioned above and why using the "state" variable can prevent it?

Your question basically boils down to why do you need CSRF tokens on a login flow?
First off, CSRF protection is to prevent (OWASP):

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application

Now consider if your login flow -- whether that is a simple Form POST with username / password, or something as complex as OAuth2 -- is not protected against CSRF attacks. The user (victim) could be logged in to your app. Another tab (the attacker) could do a POST to your login page with the attacker's credentials (or OAuth2 claim). Your app would accept the attacker's credentials (it's a real account after all) and set the right cookies in the victim's browser so that they are now logged in as the attacker. This is called a Login CSRF Attack because the attacker has forced the victim to execute the unwanted action of logging in to the attacker's account.
Maybe the victim does not notice that they are now in a different account; or maybe the UI has not refreshed and still shows them logged in as them self. Imagine if they enter their credit card information into the attacker's account!

I also need to point out a couple of security flaws in your description:

a randomly generated md5 string as "state"

If you're starting with a random value, why hash it with md5? Why not just use the random value directly? Or a type 4 random GUID? If you do need to hash it, why use an old broken hash function rather than SHA-256?

My backend first checks whether the "state" in cookie matches the "state" in the response.

CSRF tokens in cookies are brittle. At minimum, you need to set SameSite=Strict on your cookie (Mozilla docs). It is always better to put CSRF tokens in a non-cookie header, but I guess if you need the CSRF token on the OAuth2 302 redirect, maybe cookie is your only option?

TL;DR login CSRF attacks are where an attacker can force the user (victim) to log into the attacker's account. You need a CSRF token on your login pages (specifically on the login POST) in order to prevent this.
There is a good related answer on this Stack Overflow post:

https://stackoverflow.com/a/15350123/1907046


Authorization Code: Is there a specific format it has to follow? I am currently digging into OAuth 2.0 and especially the authorization code grant. What I couldn't find from within RFC6749 is if the authorization code has to follow a specific format.
The RFC says that "[...] Authorization codes operate as plaintext bearer credentials". Does that mean it is up to the authorization server to what form it takes? I mean is it just a random string that can be considered a one-time-password?

As the authorization server you issue the code, and as the authorization server you receive the code and exchange it for the requested token. The caller treats it as an opaque value. They receive it from the authorization server, and then forward it to the authorization server to get the token they asked for.
As such, the format is up to you. Generally folks often use a random key that refers to something in a database, kinda sorta similar to a session key. Others encrypt a blob containing the token itself.
The only real requirements are that it isn't guessable, doesn't leak the token, and can't be replayed.


Are services who offer to pay you a rent for your unused hard disk space a scam, and how do they work? I've seen several services advertised on social media which claim to pay me a rent if I let them use my unused hard disk space. There is usually a nice-sounding explanation about cloud storage and being able to earn money while being part of a community, and so on.

However, these days cloud storage is very cheap, and service providers can buy or rent storage facilities in mindbogglingly huge amounts relatively cheaply. I don't see why they would be interested in paying me in the magnitude of several dollars per day for a few hundred GB on an unreliable machine with unknown uptime. An off-the shelf 4 TB hard disk costs less then $200, so this "service" would return the investment in a few days.

What is the catch? Are such services just thinly disguised botnets / data thieves, or can there be a legitimate and non-malicious usage?

Can this be for real?

You have already done the math: $200 would buy 4TB of storage space, and half that sum again will connect it to the Internet with an (almost) unlimited bandwidth for one month. Supposing twenty months' life expectancy for the hard disk for ease, we get around 30 USD per month per terabyte with a DIY scheme.

Since your PC is unreliable, whoever rents it for "cloud storage" would need to use a Redundant Array of Inexpensive Donors :-). Also, they'd need a complex RAID-10 architecture to cope with the fact that most people is connected with asymmetric DSLs, so they can't upload at the same speed that some "cloud user" is needing and willing to download.

All in all, for the system to even begin to be feasible you'd need to the tune of ten physical terabytes for every logical terabyte you offer, while with a "real" disk you'd be almost one on one.

And with these ten terabytes donated by the common guy, they need to compete with DIY cloud services at 30 USD per month.

Actually they're competing with even less expensive professional outfits such as Amazon and their level of economy of scale (and service level agreements. You have to undercut their prices by a hefty margin to convince someone to store their files in what I'd call Fog Storage).

So if they offer to pay more than around 3 dollars a month for a whole terabyte, they cannot be after storage space to offer to the cloud at market prices.

The syllogism (some might-be-legit options)

The above syllogism can be falsified several ways, not all of them leading to a "it's a scam" or "illegality" sentence.

if they offer to pay...    : they might not offer to pay anything of real value to them (i.e., they don't have this cost), but supply some other advantage to get people to join. A fair exchange of disk space on other people's computers for example: you're their backup, they are yours. The users, not the service guys, are actually those "paying" each other. The business model then must rely on some other source of income: a participation fee, targeted ads on the file client, in-app purchases, and so on. Or they might just hope to be bought by Amazon for a jillion bucks, or become a FaceDrive.

more than: they might pay less (and use the same business model than above). Mind you, this is not money for nothing. Disk usage costs something. Extra resource consumption does not only impact "unused" disk space and "unused" bandwidth but also energy. If you earn US$ 5 per month and end up with a utility bill increase of US$ 6, their gain (they did not have to pay for electricity to keep the disks spinning and the drive heads seeking) is your loss. This is somewhat akin to cryptocoin mining: the coins you mine aren't free, they're mostly paid with increased electricity bills.

cannot be after storage space: they could be after something else. See below.

to offer to the cloud at market prices: this particular configuration of storage space might have advantages for someone, and be worth much more than standard market prices. There might also be reasons why the same configuration isn't offered by industrial services such as Amazon, so this particular option could be a seller's market.

So what might they be after (the don't-do-that option)?

Well, for the contract that turns your PC's hard drive space into a cloud storage to work, the following things should be granted and found perfectly unsuspicious:

access to your hard disk. Oh yes, only the unused areas (look there: isn't that Santa Claus?).
capability of sending lots of data on the Internet. Anywhere (our customers are anywhere!) and you can't see what that data actually is, it's encrypted (our customers value their privacy!).

Just the two things above are enough to:

scan your whole hard disk and look for home banking credentials, credit card details, all sorts of valuable personal information and so on.
turn your PC into a spamming relay.

Both these "features" would be quite valuable to someone, and they might be amenable to pay good money.

Especially since they needn't pay you anything. After one month service they can just disappear or say your services weren't up to spec. They might even ask for a fee to waive end-of-contract full hard disk sanitization (i.e. cancellation) as specified in a contract not everyone would read or understand. Or they might increase resource consumption so much on your machine, that you will ask for cancellation (and therefore be uneligible for any refund).

Another possibility is that the piece we're missing is "storage space at market prices". What if it's a different market? What if what they're after is completely untraceable disk storage, placed in dozens of separate private homes overseas, very difficult to even track, let alone seize or impound? Again, I can think of several people who would pay good money in order to gain this level of protection. What they would store on this fragmented data space is better left unthought.

And it still would be possible to lower costs by not paying the disk donors. Any software architecture that's capable of dealing with people turning off their PC's whenever they like (and they're saying this architecture exists, and they're using it) is ipso facto capable of dealing with people turning off their PC's because it dawns to them they're being ripped off. Therefore, I can't say that it is, but I believe that ripping off people could be a viable business model.


How to reduce the size of a key established with Diffie-Hellman? When I generate a key with the a Diffie Hellman method (DH), the established shared key will be of the same size as the prime which is used.
As far as I have read this should be at least 2000 bits for the classical DH, some say even more.

But normally 256 or 512 bits are needed for a symmetric scheme.

I have heard that it should be enough to just hash the established key to reduce the size, but some use a key derivation function.

Now I ask myself what is the standard way to do this?
Also is it more secure to use a key derivation function?

I would appreciate if you could name the methods that are used and were I could read more about such methods.

Diffie-Hellman allows two parties to generate a secret value that cannot be reconstructed from observing their communications. The size of the secret value resulting from the key exchange (ga b mod p) is indeed the same size as the prime, however its entropy may be less if a and b are chosen in a smaller space. Picking a and b to be 256-bit random numbers gives you 128-bit security for the resulting secret value.

In principle, the resulting secret value has some mathematical structure, and you shouldn't use it as is. Instead, you should hash it and use the result as your symmetric key. More precisely, you should use the shared secret as input to a key derivation function. Not a password-based key derivation function: the secret value has sufficient entropy and doesn't need to be strengthened, only stretched.

RFC 2631 specifies a way to derive key material from the shared secret: SHA-1(ZZ || type || ctr) where ZZ is a byte encoding of the shared secret, type indicates what kind of material is being derived, and ctr is a byte encoding of a counter. It's obviously ok to use another hashing function such as SHA-256 or SHA-512 instead of SHA-1.

The exact way the key material is derived isn't actually important, as long as the two parties agree. For example, if you only need 256 bits, then SHA-256(ZZ) would be ok. The point of tacking on a counter is when you need more than what one run of the hash function can provide. In the interest of future-proofing your protocol, it would be advisable to follow the RFC. If you only need to derive one key now, you can hard-code the corresponding ASN.1 encoding of the type and counter as a string literal in your application.

Actually, it turns out that using the DH shared secret directly is “not too bad”. Nonetheless, you should wring it through a KDF (at least hash it): it's easy, quick, more secure, more standard, and more future-proof.


Can my University see what Stack exchange account I am logged into? I have to log into an account to use the university internet, so I imagine they can see all the sites I view, but can they see what account I am logged into, and can I do anything to hide this?

If you use http to access stackexchange, the university can access which account you are logged in with, as there is a link to your own account in the top bar. Note that it is a theoretical "can".

If you use https and there is no university certificate or compromising software on the device you use, the university can't know that without using some very hard and unlikely timing attacks (check when you sent something that looks like a post request, when the same time appeared a new question on the network). If you use https, the only history that's sent is which server you communicate with, how much you speak with it, and when. The "history" is in the GET headers and already encrypted. You can read more about HTTPS in the link suggested by DisplayName.


Authentication concept for sites served to another site We are going to serve content to a Content Management System that embeds it through an iframe (yuck). Some pages that we serve need to be authenticated before – only a valid user should be able to see them.

The company who previously implemented what we're about to do did this through the requests. Of course, since there was no session management. The use of iframes kinda made it impossible to use cookies, etc. This is no real authentication, but that's what they did…

http://example.com/get.php?ID=1234&email=alice@example.com

Believe it or not: One could easily get the content of another user by exchanging ID or e-mail. Now we want (or, have) to change that. The problem is that we do not have access to the customer data. We don't know e-mail address and user IDs of the CMS.

The initial plan that had been developed was to send us a salted hash with e-mail and ID, and somebody thought it was possible to extract e-mail and ID from the hash again if we knew the salt. Well, turns out they didn't know how hashes work… so it's on me to come up with something new.

Here is the first scenario I thought of:

In this case we only receive a list of valid hashes from the CMS and check if the hash the user sent us is valid. The problem here is that we need a list of hashes and the CMS needs to send them to our backend some way. Is there any other issue I'm missing? What about users trying all possible hashes?

Second scenario:

We receive the user's hash and send it back to the CMS. The CMS verifies that this hash really exists and tells us whether we can serve the content. Here, the problem is that extra requests have to be made (performance?).

Third scenario – which I think should fit in our case:

The user sends us their e-mail, ID and the hash the CMS generated for them. We share a secret key (the salt) with the CMS, and try to reconstruct the hash from e-mail and ID. If it matches, the user must've been authenticated in the CMS before, so we can serve the content.

The problem here is that we send the e-mail via URL. Now, the previous (insecure) implementation also did this, but I don't know how much of a privacy issue this is.

Bottom line: Is there anything I've missed in the above examples? Would the last scenario fit our case, or is there another easy method to authenticate a user when you don't have access to private data on your side of the scheme?

This proposed design does not take replay attacks into consideration.   In the first scenario the "hash" is now the password, and therefore this hash (and the information used to create this hash),  must be protected in the database and during transmission.

What you are trying to do is not new or unique.  When you build something from scratch there are problems with design, implementation and compatibility with other systems.   To avoid all of these pitfalls you should implement an RFC'ed standard such as 3-legged oauth:


Which is more secure for a reset password feature - security questions or reset link in email? I need to provide the Reset Password Feature for my product. For this I have two competing solutions:

Send the password reset link in mail to the user
Provide the Security Question based solution

Based on the assessment by our security team, the security questions are deemed not secure. The reason is that security questions generally ask for personal information like in which city you met your spouse, name of your elementary school etc. This type of personal information widely available on the net courtesy the social media.

So, is this assessment correct and should the security question based solution for reset password be avoided?

I agree with your security team. The "security question" is not secure on its own: cities can be found over ip, names can be googled and nicknames of pets can be guessed.

However, you could combine both methods: first send the mail, and when the user clicks the link, ask the question. This way you would add at least a bit more security to the procedere. Also think about a lock (e.g. 12 hours) after three bad attempts to ensure bruteforcing isn't possible.


Will enforcing this restriction on Domain Admins "break the network"? Let's say we secure all servers in the domain..

Domain controllers allow RDP access only from jump servers
Domain admins can't connect to non-dc servers
And so forth

This is all swell and should be considered a safe configuration to prevent the existence of a domain admin's password in the memory of any member server.

Now let's say an attacker magically manages to apprehend a domain admin password on one of the member servers, then runs Mimikatz (or any other password extracting tool for that matter) through PsExec remotely on the DC - game over.

However, if I enforce the

  Deny access to this computer from the network

on DCs and configure it for all Domain Admins, will something break?

There's also a reasoning behind this, where in no case should domain admins authenticate to the DC from another server, except from the jump server.

I have modeled this in my lab and nothing breaks, and running psexec with the domain admin password fails because of this configuration. this is a win. question is, will it work in a real network?

From what I gathered, this restriction is for any auth attempt made over SMB.

Should maybe be moved to Server Fault.

The ESAE (Red) Forest is now the goto recommendation for securing Active Directory.  https://technet.microsoft.com/en-us/windows-server-docs/security/securing-privileged-access/securing-privileged-access-reference-material

Without knowing the intricacies of your network, its hard to say for sure, but Domain Admins do not require network access to Domain Controllers that I know of, but it could be a risky move without testing.  That being said, you would obviously require physical access to those devices.

The better solution is to used a tiered model for privileged access where DCs are Tier 0, member servers or sensitive servers are tier 1, tier two is desktops.  There should be no vertical traversal of accounts, so an admin may have a t0 account for DCs, t1 for member servers and t2 for desktop mgmt, and t3 for end user use.  None of those can access other tiers.  You can take that a step further with protected access workstations (PAW)(see link above).

If your DAs can't access your member servers, then a compromise of a member server in and of itself can't reveal a domain admin.  They would have to continue to jump or find other short comings where processes or tools leak data between tiers.  That is where the PAW comes in where you have a physical device with IPSec that is the only device allowed to connect to a DC, and no other account can access that device.  Then you would have to have physical access in order to compromise DA and since that DA can only be used on that physical device, Mimikatz would never see it in use anywhere else.

Note: This gets more complicated if there are non-windows devices to manage.  This also doesn't matter if you aren't 100% up to date on patches and don't follow other basic security practices like not running java/adobe on servers/DCs, restricting internet access to servers/DCs, implement network segmentation, etc.

Feel free to reach out if you want to discuss further.


When to complete PCI DSS Compliance Paperwork I am working for a startup that will soon begin processing payments with Stripe.

Looking at their documentation, it seems we will have to file an SAQ A, SAQ A-EP, or an SAQ D depending on our integration method.

How soon will we need to submit one of these documents? It seems they are filed on an annual basis, but does it need to be done before accepting payments, or is something that can be filed within a year from when we first start accepting payments?

Additionally, is there a certain threshold - $'s or # of transactions - that changes the answer to that question? Since we are a new business, it may take some time for us to reach 20k transaction threshold.

Thanks in advance !

As you'll be processing payments, your acquirer should ask you to demonstrate compliance. Alternatively, other partners may request you demonstrate compliance. It's entirely possible no one will ask you to demonstrate compliance for some time.

If you're a merchant and transacting less than 6 million Visa or Mastercard transactions per year, you can self-assess using the relevant SAQ.

If you're a service provider and transacting less than 250k Visa or Mastercard transactions per year, you can self-assess using SAQ D.

If you are above either of the above thresholds, you're a Level 1 Merchant or Service Provider and will not be able to self-assess. You will need a QSA to perform an on-site assessment and complete a Report on Compliance.

If no one asks you to demonstrate compliance, you should still ensure you're familiar with the requirements and have the requisite security processes in place.


OpenSSL version 1.0.1e in CentOS 6 -- Heartbleed Vulnerability I was reading the Heartbleed vulnerability in the OpenSSL and in its official website, they have a list which mentioned that version 1.0.1 to 1.0.1f are affected, as shown in below pic.

I have CentOS 6 installed in my server and updated as per latest available versions in yum repository.

redhat release -
[root@SERVER ~]# cat /etc/redhat-release
CentOS release 6.8 (Final)

uname output -
[root@SERVER ~]# uname -a
Linux SERVER 2.6.32-504.16.2.el6.x86_64 #1 SMP Wed Apr 22 06:48:29 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Now, when i am checking for OpenSSL version, it shows me the below information -
[root@SERVER ~]# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

So, in version output, i am able to see that version is 1.0.1e which is affected with Heartbleed Vulnerability and it also shows me that version was last updated on 11 Feb 2013.

I have following doubts --

Does this means all the CentOS 6 machines are affected with Heartbleed ?
RedHat is not providing patches for CentOS ?
What should i do now ? Manually install the latest OpenSSL package OR migrate to CentOS 7 (although i am not sure whether CentOS 7 contains updated packages or not) ?

Most distributors don't just upgrade to the latest version of OpenSSL since this could have unintended side effects (slightly different behavior or even new bugs). Instead they just backport the patch and keep the version number. This means you should not only look at the openssl version but at the distributors version number to.

For CentOS 6.8 this is currently OpenSSL 1.0.1e but vendor release 48.el6_8.3. This release includes all recent bugfixes and also the fix for Heartbleed:

* Mon Apr 07 2014 TomÃ¡Å¡ MrÃ¡z <tmraz@redhat.com> 1.0.1e-23
  - fix CVE-2014-0160 - information disclosure in TLS heartbeat extension


Accessing Nmap flags in Nmap script (NSE) I'm finishing an Nmap script that needs to create a file as part of the output (an image) which doesn't make sense to print or embed in the standard Nmap output. Currently I'm naming the output image.jpg, but I'd like use the input of the -oA/-oN/-oX/-oS/-oG flag to make the name of the output file less likely to conflict with anything in the current directory.

I've done some digging but I haven't found any way to access the flags passed to Nmap.

Is it possible to access these flags from inside an NSE, and if so, how?

There is not a way in the current NSE API to access that information. Most of the scripts that save output to files take a filename or target directory as a script-arg. I've just opened a new issue on Github to address this idea, so we'll see if we can improve this in the future.


How can I securely develop a local webapp at a coffee shop? When I'm developing a webapp, let's say a Django site, I run it locally and typically access it at http://localhost.

I thought this was inherently secure because I assumed that localhost can only be accessed locally. However, I discovered that even running a local web server (Apache, Nginx...) with a self-signed HTTPS certificate won't help because localhost is not really required to be local:

  In empirical testing, we've seen multiple resolvers... send localhost queries to the network... As a result accessing "https://localhost", say, on a hostile WiFi access point (such as your coffee shops) can be intercepted by a network attacker and redirected to a site (or a certificate) of their choosing. (In email chain "Exception to Baseline Requirements, section 7.1.4.2.1".)

If I'm developing a webapp, I need to run it locally and access it through a browser. Sometimes I need to do this at a coffee shop with an internet connection. What access point should I use, if not localhost?

Note

Some of my desktop applications also expose themselves via HTTP at other ports, for example http://localhost:9000. Presumably I shouldn't access those at a coffee shop either?

Safely developing against localhost can be done provided:

your machine is configured to resolve localhost to a loopback address (note, it's possible to change your hosts file to resolve localhost to a different address)
your machine is configured to route the loopback address via the loopback interface (it's possible to route loopback addresses to non loopback interface)
you configure your application to listen on the loopback address, not 0.0.0.0 (many web frameworks listens on 0.0.0.0 by default, this is probably the most common reason for unexpectedly exposing services to untrusted network during development)
if you use a proxy, your browser is configured not to route localhost/loopback through the proxy

In other words, a fairly typical networking configuration.

Also, take care that your database server aren't binding to 0.0.0.0, as that'll allow anyone on the network to connect directly to the database server. It's probably best to set a firewall configuration so you know exactly what ports and addresses that local services are listening on.

The link you pointed is under the context of a publicly trusted CA issuing certificates with "localhost" name. This is unsafe under that context because the recipient of such certificate may use the certificate to intercept the communication of someone with some unusual networking configurations. When you have full control over your own machine's configuration and you know that you don't have some weird configurations on your machines, the loopback interface is safe.


How do I protect myself against 'hole 196'? I came across this question a while ago and read about hole 196.

  Is there something I can install on my laptop to protect it against WPA2 Hole196?

  Software (such as Snort or DecaffeintID) can be installed on some Windows and Linux laptops to detect ARP poisoning, though it's not practical to manually install software on large number of endpoints. Further, the software is not supported on most endpoints (e.g., iPhones, iPads, Blackberry, Windows Mobile, Windows 7, etc.) that will continue to be at risk from the WPA 2 Hole196 vulnerability. Besides, those softwares cannot stop a malicious insider from launching other Hole196 based attacks such as malware injection, port scanning, denial of service, etc.

My question is, technically speaking, what other things can I do to possibly cover myself?

Most security researchers consider "hole 196"  to be more of a technical break than something that is very useful to the attacker.  I think that the WPA-PSK handshake,  and the lack of encryption for for management frames are far more serious threats.

Although hole 196 can be used in conjunction with these attacks.  1) de-auth a client, 2) capture the handshake when they re-auth and then brute force the challenge response 3) use hole 196 to obtain traffic

However,  you can defend against hole 196 by using a VPN.   The problem is that if someone else is authenticated to the wireless network then they are able to observe some of your traffic.  Simple,  if you use an SSL VPN to get out of the wireless network,  then they won't be able to see anything useful.


How secure is a partial 64bit hash of a SHA1 160bit hash? So http://en.wikipedia.org/wiki/SHA-1

  SHA-1 produces a 160-bit (20-byte) hash value

and

  As of 2012, the most efficient attack against SHA-1 is considered to be the one by Marc Stevens with an estimated cost of $2.77M to break a single hash value by renting CPU power from cloud servers

With a theoretical attack taking 2^60 operations

So if a custom verification algorithm only the first 64bits of the full hash how secure is that?

How many operations would it require?

The attack described by Marc Stevens, and all other known attacks on SHA-1 as well, are about collisions. Finding a collision is about finding two distinct sequences of bits m and m' such that both hash to the same value.

Collisions are irrelevant to the use of SHA-1 for verification. When using SHA-1 for verifying some data, there is a hash value v, and the attacker's goal is to find a bit sequence m (e.g., a password, if we are talking about verifying passwords) such that m hashes to v. This is called a preimage and it is not the same animal at all as collisions. For all we know, SHA-1's resistance to preimages is as good as new.

Let's put some numbers on it. For a hash function with n bits of output, a collision can be found with average cost 2n/2 evaluations of the hash function (this is related to the so-called birthday paradox) so this would amount to about 280 calls to SHA-1 for the full function. This kind of attack is completely generic, it works with all hash functions; Stevens' attack is considered a break because it does better, down to an estimated cost of 261 evaluations of the function: half a million times faster than the generic attack, but still quite expensive (261 is about 2 billions of billions). If you truncate the output to 64 bits then the generic attack cost is down to 232 and a PC will be able to find a collision in a few minutes. Fortunately, as I said above, collisions don't impact the use of the hash function for verification, since that use relies on resistance to preimages.

For preimages, a generic attack on hash function is called "get lucky": try random input sequences m until one is found that matches the target output. For a hash function with an output of n bits, this has average cost 2n. For the full SHA-1, this leads to 2160 which is very far in the unfeasible realm (quite beyond the "sci-fi feasible", even). If you truncate the SHA-1 output to 64 bits, then that cost goes down to 264, which is technologically feasible, but will be expensive. Let's estimate the cost: a good GPU costing a few hundreds of dollars will go through about 2 billions of SHA-1 computations per second, let's say 231 to make computations easy; so that GPU will need about 233 seconds to run the preimage attack (because 264 = 233*231). 233 seconds, that's 272 years... If you put 3000 such GPU to the task (so that's a million dollar cost for the hardware alone), it will take about one month to find a 64-bit preimage.

FPGA might lower the hardware cost, but will increase development costs a lot, because that's no longer a matter of putting together some off-the-shelf PC. A practical attacker will rent GPU time from big cloud provider such as Amazon EC2 (their "CG1 instances" are what the attacker would use in this case).

Therefore, for many purposes where what the hash/verification system protects in not too expensive in itself, truncating the SHA-1 output to 64 bits will not imply an actual security vulnerability.

Now the important notes:

All of the above assumes that SHA-1 truncated to 64 bits (let's call it SHA-1/64) is as good against preimages as can be expected from a "perfect" hash function, and as SHA-1 itself seems to be with its full 160 bits. It can be shown that SHA-1/64 cannot be too weak against preimages, because a very fast attack against SHA-1/64 could be turned into an attack against the full SHA-1 which would be faster than 2160 (not fast, but faster, which would be enough for an academic paper). No such attack is known, so it can be assumed that SHA-1/64 is probably resistant to preimage up to cost 264.
If you are hashing passwords then you are doing it wrong. Password hashing has some special needs, because passwords are inherently weak (humans accept to remember them and to type them, so they cannot be strong). When dealing with passwords, the biggest vulnerability is the password itself, not the hashing function. SHA-1/64, or SHA-1, are by themselves very poor, because they are very fast, and unsalted (which allows for precomputations and parallel attacks). Please read this answer which will tell you how password hashing should be done.

(If you are hashing passwords then the answer to your question "how many operations would it require ?" will be the same for SHA-1/64 and for the full SHA-1, i.e.: about one billion. Because user-chosen passwords rarely exceed 30 bits of entropy. A good GPU will need less than a second to do that...)


How can CloudFlare provide a valid SSL certificate for domains not under its control? CloudFlare provides a reverse proxy, and it offers SSL support ("flexible", "full", "strict full", and "keyless").

How does CloudFlare manage to get a valid certificate for domains it does not own? Don't the certificate authorities normally require proof that you own the domain, at the very least sending a verification email to an email address of that domain? How does CloudFlare skip this step?

Simply put, the webmaster of the site uploads the certificate to CloudFlare.

See this article for details.

The Keyless mode doesn't have this requirement. It uses an on premise key server instead, to provide the private key of the server. See the diagram here for details on how this works.

For free accounts

Cloudflare state in their blog:

  For all customers, we will now automatically provision a SSL
  certificate on CloudFlare's network that will accept HTTPS connections
  for a customer's domain and subdomains. Those certificates include an
  entry for the root domain (e.g., example.com) as well as a wildcard
  entry for all first-level subdomains (e.g., www.example.com,
  blog.example.com, etc.).

Cloudflare do control the domain, because the customer has pointed their DNS records to it, this means that they can gain a Domain Validated certificate. Domain validation procedures do not have to involve sending an email to the domain, which wouldn't be possible for Cloudflare to intercept because the MX record is not repointed. They can instead prove that they own the domain by putting a randomly named text file containing a random key for the CA to query in order to prove control of the domain. The CA will specify the name and contents of this file that they will then be able to check. Cloudflare could then intercept requests for the URL and display the necessary validation code.


Can GET Requests with Spring Rest controllers be intercepted by attackers? I'm building a Spring app and a React app which also contains Chat functionality. I use WebSocket with RabbitMQ as message broker.

I store the chat history as encrypted messages with AES, and before I send them to the client, I decrypt them. So I'm wondering if someone could "intercept" the GET request and actually see the messages? I use JWT as authorisation, so to get the messages, the user of course has to be logged in. Also is it better to decrypt the messages in the backend or send the key and encrypted messages to be decrypted in the frontend?

I know it's better to use a hybrid of AES and RSA, and to send the private key with SSL, however, this is just for a bachelor thesis so writing about it in the report is "good enough". I don't have enough time to implement the hybrid version. I do however want to keep the chat the most secure I can.

So really my questions are: Can GET requests be "captured" by attackers even when you have to be authenticated to call the requests, and since I have to use symmetric cryptography, is it better  to decrypt the messages in the backend or sending key and encrypted messages to frontend?

As long as you use TLS in the websocket, the requests between the server and the clients are going to be encrypted, so you don't need to encrypt again the messages.
Encrypting them with AES on server-side to provide encryption at rest should be more than enough.

If you don't use TLS, then yes, the attackers could sniff the traffic and extract the content, but sending the key along with the encrypted message is not solving anything, since you also provide the attacker the way to see the original message.

Also, another drawback to send the decryption key to the frontend, is that you are sending the key to a client that you do not control, which can cause more problems:

You send the decryption key to an endpoint that you do not control
If there is only one key in the server for all the conversations, you are giving the key of decryption to a possible attacker that could compromise the message database.


When would one use a password hash instead of a KDF? From what I'm reading, for storing passwords it is recommended to use a KDF (like Bcrypt). If it is more secure to use a KDF for handling passwords, when would you use a password hash instead?

A password hash is a KDF, but not all KDFs are password hashes. Password hashes have the additional requirement that they allow configuring how slow they are, while some KDFs do not have this ability.

For instance, HKDF is a KDF designed to allow deriving keys from an existing high-entropy key. This is useful when you already have a single key (either generated randomly or from a slow KDF like bcrypt, Argon2, PBKDF2, etc), but need multiple keys.


Using a separate email address for each contact A lot of the people I exchange emails with use services such as Google Mail.  Recently it occurred to me that Google must maintain a social graph based on who exchanges emails with whom.  It bogs me that a Google employee can potentially point to a number of email addresses and say: "These are the individuals X is in touch with."

How about the following approach to rendering the latter a tad more difficult:

When I mail someone for the first time, a generic-sounding address (e.g. eva.sanchez@example.es or jon.smith@example.co.uk) is generated.
The new address is associated with the receiver.
The email is sent with the newly generated address being used as the sender.
Whenever that specific receiver wants to mail me, they will use the address generated in the first step.

Now for the questions:

Does anyone use such a scheme?
Do you think it's any good at all?
Are there existing solutions?
What Linux mail client might prove suitable for adding this functionality?
How to automate the generation of new addresses?  Is there a provider offering an API that is sufficiently capable?

Does anyone use such a scheme?

Yes. I know several people who run their a mail server on their own domain.  Every new contacts is treated as a potential spammer and everybody gets an unique email address.

  Do you think it's any good at all?

That depends on your goals.

It suffices for your "2) address is associated with the receiver."
It is not enough to prevent your ISP or mail provider to track you.

  Are there existing solutions?

The closest thing I can come up with are sites such as http://www.mailinator.com/ and http://spamgourmet.com/ . Those are used by lots of people, which means that you can not be tracked down just by looking at the domain. However you still have to trust the mail provider not to leak information.

  What Linux mail client might prove suitable for adding this functionality?

No idea.

  How to automate the generation of new addresses? Is there a provider offering an API that is sufficiently capable?

That depends on the previous answer.


Why use anything other than RSA for transmission encryption? Being fairly new to the cryptography and data security space, I have sampled a few "Introduction to cryptography" sites/textbooks and they all seem to start in the same general way:

This is a Caesar Cipher
This is Frequency Analysis
This is rolling cipher encryption
...
This is DES, 3DES, ...
This is RSA. Oh, and by the way, for all intents and purposes, it's unbreakable.

I understand the educational value of explaining older ciphers and ciphers but in reality, if I need secure digital communication over an insecure channel, why would I ever use anything other than RSA?

RSA (and other public key cryptosystems) is extremely computationally expensive, making it impractical to use it to encrypt an entire transaction. So public-key encryption is generally used only to agree on a symmetric encryption key, which is then used to encrypt the rest of the transaction using a symmetric algorithm such as AES or 3DES.

See the accepted answer to this question for more details.


How to add X-Frame-Options header to a simple HTML file? I am having trouble adding X-Frame-Options header to a simple HTML file.

Is there any way to do it using JavaScript?

X-Frame-Options is an HTTP header. As such, it's not part of HTML and can't be set inside an HTML document.

One reason why it's an HTTP header only is that clients should be able to decide if the document is allowed to be embedded in a frame before parsing the HTML code.

Hence, you can't achieve that by editing the file but you need to modify the server's HTTP response. Typically, this is done in the settings provided by the web server software or with a server-side language.

E.g., a setting in Apache could look like this:

Header always append X-Frame-Options DENY

Or, in PHP you could set the header like that:

<?php header('X-Frame-Options: DENY'); ?>

Note that there is a more modern CSP equivalent frame-ancestors. But while some CSP policies can be set as <meta> tags, that's not possible here. This does not work:

<head>
  <!-- This does *not* work! -->
  <meta http-equiv="Content-Security-Policy" content="frame-ancestors 'none'">
</head>

Also have a look at the Clickjacking Defense Cheat Sheet for an overview of clickjacking defense measures beyond setting the XFO header.


Personal Information / Compliance in SaaS for US-based customers What compliance issues should any B2B SaaS provider worry about when saving user information to its databases such as Name, DOB, Gender, Emergency Contact Information (Name, Phone, Address), etc.

Does any of this trigger HIPAA or anything like that?

This is a very broad question, but I can provide a general answer.

HIPAA would only be involved if you're storing data related to health care, such as appointments or communication between a patient and health care provider.

However, you'd be in scope for various privacy regulations both extant and proposed, because you're dealing with personally identifiable information (PII).

Notably, there are several states with privacy regulations that this information would be patently in scope for:  California, Nevada and Massachusetts.

The soon-to-be-effective California Consumer Privacy Act (CCPA) would also introduce GDPR-like protections to this data for US-based customers.

Here's a short summary from Wikipedia (https://en.wikipedia.org/wiki/Personal_data#United_States):

California

The California state constitution declares privacy an inalienable right in Article 1, Section 1.
California Online Privacy Protection Act (OPPA) of 2003
SB 1386 requires organizations to notify individuals when PII (in combination with one or more additional, specific data elements) is known or believed to be acquired by an unauthorized person.
In 2011, the California State Supreme Court ruled that a person's ZIP code is PII.

Nevada

Nevada Revised Statutes 603A-Security of Personal Information

Massachusetts

201 CMR 17.00: Standards for The Protection of Personal Information of Residents of the Commonwealth[34]
In 2013, the Massachusetts Supreme Court ruled that ZIP codes are PII.[35]


Why doesn't CVSSv2 consider XSS to have a confidentiality impact? From the CVSSv2 specification:

  SCORING TIP #2: When scoring a vulnerability, consider the direct impact to the target host only. For example, consider a cross-site scripting vulnerability: the impact to a user's system could be much greater than the impact to the target host. However, this is an indirect impact. Cross-site scripting vulnerabilities should be scored with no impact to confidentiality or availability, and partial impact to integrity CVSSv2 spec

This is also how I have seen XSS be scored in practice.

But even if we only consider the impact on the host, an attacker could use a JavaScript payload that reads out sensitive information from the affected web-application (if the victim is currently logged in of course, and if such sensitive information exists).

So why isn't confidentiality rated as low? Is this an indirect impact? And if so, why (and why isn't the integrity impact indirect then)?. And for that matter, why isn't there an availability impact? Couldn't an attacker bypass CSRF protection and thus possibly (depending on the application of course) delete important data or change settings to make the application unavailable?

Related: Why is XSS scored with partial impact to integrity in CVSS V2?.

I know this has been changed in CVSSv3 (because now the browser is considered instead of the host).

The answer is pretty simple. Since its an indirect effect of the XSS.
Example: A vulnerability that allows you to read the cookies would have a confidentiality impact.
But a vulnerability that allows you to inject XSS has a integrity impact (allows you to change the page), but as you can arbitarily change the page, to a malicious page that steals the cookies, the scoring does not take consideration to the indirect vulnerabilitys that are found.

Take for example this:
A vulnerability in a download script allows a attacker to replace the EXE that is being downloaded. It would have pretty high integrity impact.

But it does not have a confidentiality impact just because the malicious EXE being downloaded could leak information.

Same with XSS. This scoring is important as the remediation of the vulnerability is to solve it at its source (remove the possibility of XSS by filtering better). Improving the confidentiality won't solve this without incurring unintended side effects, and on top of that, the XSS would remain in the web application, causing the vulnerability to still be in effect (the CVE can't be registred as solved) because theres other risk's than confidentiality risks.

The CVSSv3 system does have a few other vectors added that compensate for this, thats why its also is changed in CVSSv3. (with the scope change metrics, which take in consideration if the effect of the attack happens somewhere else, and this can then be considered when mitigating the vulnerability)


Question about the cause of the differences in Google Pay features If you are logged in with your Google account and click "Manage your Google Account," you can then edit your payment profile. But you cannot (1) see the complete card number except for the last 4 digits or (2) change the number of an existing card. You are only allowed to (1) edit other information of the card like CVC and billing address or (2) remove the card.
By contrast, if you use Google Pay at the checkout page of a seller's website, you will find that you can see your actual card number and edit it, but right-click is disabled on the payment form (What is the reason for this?).
I am wondering whether there are any security concerns involved that cause the differences. Does the actual credit card number in the latter scenario stay in the application memory? If so, what is the chance of a user's RAM being hacked and his credit card information getting stolen?

Most likely, Google withholds the full number of the credit card as a way to prevent someone else that got access into your account to get it. They only reveal the last four digits so that you can discern which credit card it has. This implies that you are not allowed to edit the credit card number, as that would allow the user to view the full number. Removing the card and adding a new one works well, instead. (Plus, they probably have some internal identifier to link this card with purchases, so internally they probably want as well that a new card is set up as a new object, not as a change of an old one)
However, you found out that

if you use Google Pay at the checkout page of a seller's website, you will find that you can see your actual card number and edit it

I would consider this a result of the implementation of this particular seller. The seller API clearly lets them know the full credit card number (this could be needed to linking a chargeback to card XYZ with a purchase, or if they are handling directly the communication with the merchant). The seller page also allows you to change the credit card number on-the-fly. Which is a good feature from an UX point of view. However, showing the full credit card number here misses the point of actually attempting to hide it from the user (note that credit card numbers aren't considered a secret, but it isn't a good idea to make them much available, either). I think they should simply show those last characters instead.

but right-click is disabled on the payment form (What is the reason for this?).

Sometimes websites block right-clicking "for security", such as trying to "protect" the page code they sent to the user browser by blocking the contextual menu and thus making it slightly harder to view the page source. It doesn't really work, though, so that will basically only annoy users that wanted to use it (e.g. for actions as mundane as 'Copy' or 'Paste'). It makes sense to block the right click if the page implements its own contextual menu (several webmails do this) as a replacement (otherwise the user could get one upon the other), but little else.


How test if a tool doesn’t check for /extendedKeyUsage=? Web browsers are off course checking that field, but some third party libraries for languages like perl don’t perform it (they check /keyUsage= but not /extendedKeyUsage=).

So for example, I would need a certificate authority that would allow to put anything inside inside the /cn= (a field which can be typically used for subscriber in the case of s/mime certificates since the /keyusage= field allow encipherment but not for server authentication).
Badssl doesn’t offer such testing option (and probably not any other website).

Why not make your own ca? Because I’m talking about crappy stuff which have all their certificate hard coded in compiled shared objects?
Also, in my case (for the responsible disclosures I’m planning), the bug shouldn’t be hypothetical. I mean a certificate authority should deliver certificates with arbitrary websites in the /cn= fields but without server authentication in the /extendedKeyUsage= field.

What kind of certificate typically don’t allow for server encipherment in their /extendedKeyUsage= field and don’t have the /cn= part verified ? An s/mime certificate !
If such certificate get used with a web browser for man in the middle, the web browser will detect the certificate doesn’t allows server authentication in it’s /extendedKeyUsage= field an refuse it. But if a tool doesn’t check /extendedKeyUsage= field contents, man in the middle would work.

a certificate authority should deliver certificates with arbitrary websites in the /cn= fields but without server authentication in the /extendedKeyUsage= field.

"Arbitrary websites" sounds like something that you may or may not be the admin for.

Let me get this straight. You want a publicly-trusted CA (trusted by real devices out in the world) to issue you a malformed / invalid TLS server certificate (because the EKU is wrong), for the purpose of your security research? First, I would guess that most commercial CAs issuing TLS web certs are hard-coded to populate the EKU field correctly. Second, I am not an expert on the CA/Browser Forum rules, but issuing intentionally malformed / malicious certs off a publicly-trusted root seems like the kind of thing that could get a CA in a lot of trouble. Good luck finding one.

ORIGINAL ANSWER:

  I would need a certificate authority that would allow to ...

Why not make your own CA?

Whenever I'm testing cert validation stuff, I make a quick openssl CA using openssl. If the openssl command-line intimidates you (I don't blame you) then I recommend the CA.pl convenience wrapper. Add your new root CA to the trust store of whatever app you're testing and then you have the ability to produce any kind of bizarre cert you want and make sure the application rejects it properly.

(note, you sometimes need to get pretty down into the weeds of openssl config files depending on which certificate fields you're trying to manipulate or how you want it to do the signing.)


WiFi Privacy Question? I logged into a WiFi network on my MacBook at my friend's work today. She logged me in since I could only use the guest WiFi. However, her work's WiFi network under "802.1X" when I open AirPort. When I select that option in advanced, her user profile appears. If I delete the WiFi network and user profile, will all traces of it leave my computer?

Is there anyway that even if I'm not on the network and in range of WiFi, that the owners of the network could track my activity or invade my privacy in any way?

Also, I accidentally just clicked "Connect" on the network. Could anything happen, or will it notify her work?

If there's a strict policy of not letting anyone from outside the company to use the company WiFi, and if it's monitored, the logs may reveal that there was an unknown computer logged in using your friends credentials. The worst that could happen is that your friend will get some company policy based consequences, even get fired, but that's not in a scope of technological information security.

Usually the collected information could contain your MAC address, operating system type, hostname and of course it's possible to log any data transmitted during the connection. That could be used to identify you, for example if your hostname has your name in it (MBP-agr96) or if the MAC address can be otherwise be connected to you.

The MAC address could be compared afterwards even if you

delete all the traces of the connection from your clients settings as suggested
delete all the related client side logs
overwrite your entire hard drive.

The connection alone doesn't leave any tracking capabilities to your computer, but theoretically the same machine could be identified based on the the MAC address whenever you connect to a WiFi AP the same administrators have access to. In reality... ain't nobody got time for that.

Personally I'd protect company networks not only from unauthorized friends but from any unauthorized BYOD devices, too; either by using RADIUS for machine authentication instead of user authentication or by bocking any unknown MAC addresses i.e. with a MAC address whitelist.


Can someone explain the "Section 4.2.1.3. Key Usage" extension in RFC 5280 as it relates to TLS 1.2 RFC 5246 There are references in TLS 1.2 RFC 5246 about use of certificates (server and client). I am unclear about the  "key usage" extension of a certificate as it relates to TLS 1.2 and that too for data encryption only. I am not not concerned about using TLS by CAs themselves.
Here are the various key usage types:

 KeyUsage ::= BIT STRING {
       digitalSignature        (0),
       nonRepudiation          (1), -- recent editions of X.509 have
                            -- renamed this bit to contentCommitment
       keyEncipherment         (2),
       dataEncipherment        (3),
       keyAgreement            (4),
       keyCertSign             (5),
       cRLSign                 (6),
       encipherOnly            (7),
       decipherOnly            (8) }

Clearly dataEncipherment has no role to play in TLS 1.2.  Can someone provide the key extensions that do play a role in TLS 1.2 and a sentence or two explaining the specific usage of the certificate for that key extension?

There is mention of the some of these extensions in the TLS 1.2 RFC (For example in section 7.4.2). But its too brief for my knowledge level in this area.

Great question! I don't know if there's definitive source for this, so I'm going to make educated guesses based on the RFCs.

TL;DR: the following keyUsage bits are supported in TLS 1.2 for end-entity certs:

   digitalSignature        (0),
   keyEncipherment         (2),
   keyAgreement            (4),

Now let's go through the keyUsages one at a time:

digitalSignature

 KeyUsage ::= BIT STRING {
   digitalSignature        (0),

This one is obvious, this is the normal RSA or ECC certificate auth.

nonRepudiation

   nonRepudiation          (1), -- recent editions of X.509 have
                        -- renamed this bit to contentCommitment

This is typically used for legally-binding signatures, such as eIDAS. I can't imagine you'd put this on a TLS cert.

keyEncipherment

   keyEncipherment         (2),

This will correspond to TLS cipher suites with RSA key transport, like TLS_RSA_WITH_AES_256_GCM_SHA384.

From RFC 5246 (TLS1.2) Section-7.4.2 Server Certificate:

RSA                RSA public key; the certificate MUST allow the
RSA_PSK            key to be used for encryption (the
                     keyEncipherment bit MUST be set if the key
                     usage extension is present).
                     Note: RSA_PSK is defined in [TLSPSK].

dataEncipherment

   dataEncipherment        (3),

I don't think there's a use for this in TLS.

keyAgreement

   keyAgreement            (4),

This is used when you have a Diffie-Hellman key in a certificate. This is definitely less common than it used to be, and people prefer the ephemeral versions -- DHE and ECDHE -- but TLS 1.2 does support it with cipher suites like TLS_DH_RSA_WITH_AES_256_GCM_SHA384.

From RFC 5246 (TLS1.2) Section-7.4.2 Server Certificate:

DH_DSS             Diffie-Hellman public key; the keyAgreement bit
DH_RSA             MUST be set if the key usage extension is present.

keyCertSign & cRLSign

   keyCertSign             (5),

From RFC 5280 (X.509) section 4.2.1.3. Key Usage:

The keyCertSign bit is asserted when the subject public key is
  used for verifying signatures on public key certificates.  If the
  keyCertSign bit is asserted, then the cA bit in the basic
  constraints extension (Section 4.2.1.9) MUST also be asserted.

You don't (or at least, really really shouldn't) use a CA cert directly for TLS, so I wouldn't expect to see this key usage on a TLS cert.

Similarly:

   cRLSign                 (6),

From RFC 5280 (X.509) section 4.2.1.3. Key Usage:

The cRLSign bit is asserted when the subject public key is used
  for verifying signatures on certificate revocation lists (e.g.,
  CRLs, delta CRLs, or ARLs).

So you shouldn't see that key usage on a TLS cert.

encipherOnly & decipherOnly

   encipherOnly            (7),
   decipherOnly            (8) }

From RFC 5280 (X.509) section 4.2.1.3. Key Usage:

The meaning of the encipherOnly bit is undefined in the absence of
  the keyAgreement bit.  When the encipherOnly bit is asserted and
  the keyAgreement bit is also set, the subject public key may be
  used only for enciphering data while performing key agreement.

 The meaning of the decipherOnly bit is undefined in the absence of
  the keyAgreement bit.  When the decipherOnly bit is asserted and
  the keyAgreement bit is also set, the subject public key may be
  used only for deciphering data while performing key agreement.

These terms do not appear in RFC 5246, so I don't imagine a TLS server / client would know what to do with them, even if they were present


Why am I getting url requests for pages I never had on my site? On my Drupal site I'm getting strange requests for url paths that I have never had and have nothing to do with my site. Could some one explain why people (or bots) are looking for the following urls?

resource-center/news/surgery-office-pays-for-hipaa-violation
resource-center/news/state-officials-stake-out-positions-on-implementing-health-law
business-insurance/commercial-insurance/commercial-general-insurance/hotels-and-other-accommodations
resource-center/news/faq-the-obama-administration's-compromise-on-contraception-benefits
/resource-center/news/55-billion-reasons-for-consumer-driven-care

My site is for my business where we build themes for Drupal and have nothing to do with the following urls. Why am I seeing this in my Drupal reports?
(our server is setup as a multi site with out clients sites. but they don't get as much traffic as our site) The client sites also have nothing to do with any of the following links and have never had url paths of that type.

Should I block the IP address that are making the requests?

looking at the data from one of the requests:

TYPE    page not found
DATE    Thursday, October 1, 2015 - 09:20
USER    Anonymous (not verified)
LOCATION    http://www.mcmahonllc.com/resource-center/news/the-white-house-fact-sheet-on-the-contraception-compromise
REFERRER
MESSAGE resource-center/news/the-white-house-fact-sheet-on-the-contraception-compromise
SEVERITY    warning
HOSTNAME    66.249.73.183
OPERATIONS

This is all the data I have.

There's nothing malicious about this. It could simply be that someone is hitting your machines because they have an out-of-date IP address for a completely different host, maybe because it was hard-coded into a hosts file by someone or a DNS somewhere down the line isn't functioning correctly.


environment variable accessibility in Linux Perhaps this is a trivial question, but how accessible are environment variables in Linux between different users?

e.g. if Alice executes

export FAVORITE_FOOD=`cat /home/alice/fav_food.txt`

Can Eve tell what's Alice's favourite food? (Assuming both Alice and Eve are normal users, and Eve doesn't have read access to /home/alice/fav_food.txt)

Let's trace the flow of the confidential data. In this analysis, it is understood that anything Alice can do, root can also do. Also an external observer “one level up” (e.g. with physical access to snoop on the disk bus, or in the hypervisor if the code is running in the virtual machine) might be able to access the data.

First, the data is loaded from a file. Assuming that only Alice has read permission on the file and the file is not otherwise leaked, only Alice can call cat /home/alice/fav_food.txt successfully. The data is then in the memory of the cat process, where only that process can access it. The data is transmitted over a pipe from the cat command to the calling shell; only the two processes involved can see the data on the pipe. The data is then in the memory of the shell process, again private to that process.

At some point, the data will end up in the shell's environment. Depending on the shell, this may happen when the export statement is executed, or only when the shell executes an external program. At this point, the data will be an argument of an execve system call. After that call, the data will be in the environment of the child process.

The environment of a process is just as private as the rest of that process's memory (from mm->env_start to mm->env_end in the process's memory map). It's contiguous with the initial thread's stack. However, there is a special mechanism that allows other processes to view a copy of the environment: the environ file in the process's /proc directory (/proc/$pid/environ). This file is only readable by its owner, who is the user running the process (for a privileged process, that's the effective UID). (Note that the command line arguments in /proc/$pid/cmdline, on the other hand, are readable by all.) You can audit the kernel source to verify that this is the only way to leak the environment of a process.

There is another potential source for leaking the environment: during the execve call. The execve system call does not directly leak the environment. However, there is a generic audit mechanism that can log the arguments of every system call, including execve. So if auditing is enabled, the environment can be sent through the audit mechanism and end up in a log file. On a decently configured system, only the administrator has access to the log file (on my default Debian installation, it's /var/log/audit/audit.log, only readable by root, and written to by the auditd daemon running as root).

I lied above: I wrote that the memory of a process cannot be read by another process. This is in fact not true: like all unices, Linux implements the ptrace system call. This system call allows a process to inspect the memory and even execute code in the context of another process. It's what allows debuggers to exist. Only Alice can trace Alice's processes. Furthermore, if a process is privileged (setuid or setgid), only root can trace it.

Conclusion: the environment of a process is only available to the user (euid) running the process.

Note that I assume that there is no other process that might leak the data. There is no setuid root program on a normal Linux installation that might expose a process's environment. (On some older unices, ps was a setuid root program that parsed some kernel memory; some variants would happily display a process's environment to any and all. On Linux, ps is unprivileged and gets its data from /proc like everyone else.).

(Note that this applies to reasonably current versions of Linux. A very long time ago, I think in the 1.x kernel days, the environment was world-readable.)