Correct way of signing and verifying a message I have an object which I need to transmit to clients and I need the clients to know that I actually created the object. Obviously, this process involves in me signing the object with my private key, so the clients can then verify it using my public key. The only problem which I have is that there is some processing in yet another application which changes some properties inside this object. This means that I cannot sign the whole object since verification will fail. However, what I really need to verify is the Payload, which does not change. The process which I followed is the following. Please let me know if this is the correct way of doing it and point out any security flaws which there might be.

I added 2 properties in the object (SignedPayload and PublicKey)
Create a public/private key pair
Signed the Payload using the private key, and set SignedPayload
Added the public key to the PublicKey property

The middle application will now be hit, and some properties are going to change, but, the Payload will not. Ultimately, the next steps will be done once the message is received on the client:

Deserialized the message
Verify the message using the PublicKey, Payload and SignedPayload properties. If the Payload has changed, or the public key does not originate from my organization, the message is ignored. This means that I have to sign the public key.

My main questions are:

Is this approach secure?
How do I sign the public key so the client can make a check that I am the owner of the key?
From what I have read, it is common practice
to transmit the public key when signing and verifying data. Is this
correct?
Is there something wrong with the approach of creating a key pair for every
message, since I am always transmitting the public key? The reason for this is to avoid having to store the private key on the server, which can be hijacked.

Many thanks in advance.

Unless you've left out an important element, tour approach seems to have a major flaw: you're checking the validity of the payload using the public key included with the same message.

Anyone could therefore forge a valid packet simply by generating a new key pair, signing the payload and the attaching the public key to the packet. That is why your first step should always to evaluate the validity of the public key.

This is usually done by placing the public key in a signed certificate describing the claim of identity of the originator and having that certificate signed by an authority trusted by the recipient.

As for your other questions:

  Without going through a CA, how can I generate a PKI which I myself, can verify that I, and nobody else, has created that PKI?

Assuming you're simply misusing the acronym "PKI" to mean "public/private key pair" then you can't: you absolutely need to have a way to validate the public key in order to validate the message sender. Otherwise, as I described, anyone could create a packet.

That validation is what a CA is for: it allows the end user to tell that a given public key is owned by a specific security principal.

Another way of validating such a key is to use a key server: a system that hold the information linking a public key with a security principal. This could be used if you want to create a semi-anonymous transport system: if you do not want the recipient to be able to know who sent a specific payload but want it to be able to make sure it has the proper authorization and, at the same time, ensure that the central server cannot see the content of each payload. It doesn't looks like you're implementing that kind of system, though.

  From what I have read, it is common practice to transmit the public key when signing and verifying data. Is this correct?

You need to provide the public key to the end user, yes. But common practice depends on what you're doing exactly. In most cases, you'll not only have the public key but also some form of digital certificate allowing the end user to validate the key itself (if you don not have another mechanism in place to validate that public key). In the case of TLS, the common practice is to transmit ALL certificates in the trust chain (up to the root) to the client so they can check the full chain even if they are missing an intermediate certificate.

  Is there something wrong with the approach of creating a PKI for every message, since I am always transmitting the public key?

Not as such but creating a key pair is a delicate and resource-intensive operation. Unless absolutely necessary, it isn't typically implemented that way.


Which WYSIWYG editor has the best security reputation? I would like to use a pre-built WYSIWYG editor such as TinyMCE or CKEditor in a website that I'm building.

Since I expect my users to be entering confidential information into the editor it is crucial that it is as secure as possible.

Are there any WYSIWYG editors that have a particularly good reputation for security?

The problem isn't the WYSIWYG editor. They are clientside code. The problem with such editors is when they are integrated with the serverside to post content or perform an image upload.

Much of the bad reputation comes from when they are included in a CMS plugin. Those integrate with the serverside code base and either aren't always coded securely or the exploit is found in code unrelated to the WYSIWYG editor. Since the attack to the serverside originates from the WYSIWYG editor it gets the blame even though the same attack could of been done from a text area or a POST request to the vulnerable script.

Keep in mind they might provide tutorials for integrating with a serverside language. But these are just examples and shouldn't be used as production ready scripts. Unfortunately people take these scripts and run with them. So again, the blame gets put on the WYSIWYG editor despite the fault needing to be placed on a lazy developer.

Both of the editors you mentioned are pretty well maintained and you can't go wrong with either. However if you aren't using a CMS plugin the secure coding is up to you.

Edit: With the mention of XSS attacks on the clientside the same applies. Your serverside is pushing that data to the WYSIWYG editor. It expects whatever you send it is what you wish for it to display. Sanitation of malicious code needs to be done on your side before it is fed clientside.


What is encryption method for the 3rd part of the Kryptos text? http://fr.wikipedia.org/wiki/Kryptos_%28sculpture%29
http://en.wikipedia.org/wiki/Kryptos

I read the Kryptos wikipedia page, is says it's crypted with a "modular transposition of lines and columns".

What is that ? How hard it is for a non-cryptanalist ?

There are a number of useful articles written about Kryptos, that are very interesting to the amateur cryptographer such as myself - your best bet for this particular question is probably Frank Corr's post on derkeiler.

  It uses two grids of dimensions 21 x
  16 and 28 x 12. The plaintext ends up
  being written into the first grid by
  row, starting at the top row, and
  removed by column, starting with the
  last column and moving backward. It is
  then run through the second grid in
  the same way.

It is much easier to understand when described like that.


Does "Start the following program on connection" mean what I think it means? In the Programs tab of Windows' RDP application, there is a Start the following program on connection option.

Does On Connection literally mean on connection? As in will the program I specify be started after I connect and before I login, or does On Connection really mean On Login?

Thanks

It means once you've connected and logged in successfully.


Do 2 Chip based cards effect each other's data if they are in the same wallet all the time? So I got 2 new ATM cards from two different banks, both cards are Chip and NFC enabled. Card A arrived one week earlier than Card B.

Both of them remain in my wallet in close proximity to each other, separated by a thin layer of leather.

I have noticed that ever since Card B has arrived many times my chip based POS transactions on card A get declined saying Chip Error

I do know that NFC enabled card readers do get confused when 2 similar cards are there close to each other but this is about the POS credit/debit card processing machines.

I don't really think Card A's chip has gone bad on its own, its a brand new card with only 2 weeks on it.

No. To work the chips in the cards need power - which is provided by the reader (in the case of contactless payments this is done wirelessly).

I'd imagine if its a new card its most likely a manufacturing error. If these are physical transactions failing as opposed to contactless it is also worth checking the chip terminals are clean - i.e. there is not something either blocking the chips contact with a reader or shorting out two of the connection terminals.


Security Awareness Training Ideas Does anyone have any solid recommendations for deploying and maintaining security awareness training? I am not looking for a specific vendor but I am trying to gain insight about how the material is actually presented and how to test people on what they have learned.

We are a distributed company of 350 so hands on training probably won't work out.

Here is a link to a plethora of content (most if not all free). SANS has some pretty good content, but the best content you can provide is the one you create. This is because what you are looking for is so broad, it will be too much for the average person to swallow, which will ultimately defeat the point.

There is NIST SP800-50, but again, these tend to be so broad, they become 1) boring and 2) ignored. It helps immensely to personalize training around your business, not what others have made for theirs (NIST, CoBIT, ITIL) since all businesses have different goals, objectives, etc. What I have found, is that building one's own, and sending out N amount of reminders via say e-mail, works best.

I will share a story with you I had when I went for a pentest to a financial reporting company. Upon entering a company in MA, higher level management was skeptical of MOST security concepts. I explained things in analogies which helped them 'get it'. After discussing things for about an hour, they showed me a life-sized cut out poster of someone standing behind someone else holding a gun. It was a cartoony/video game like poster, but menacing. The intended message was: "this armed guy you don't see wants your password." The conveyed messages: 1) Hackers are gonna kill us 2) Security is blown out of proportion, no hackers run around with guns 3) What video game is that from?

Analogies work wonders. The average colleague is not going to immerse themselves on things like: AV*EF, Cipher-block Chaining, differences between EDE EEE, etc., however if you format it in a way that makes sense, and can carry over OUTSIDE OF WORK (e.g., how it can help keep their personal bank accounts, and personal info safe), it will work 1000x better.


Should I forbid GET for non-side effect POST by default? If a webpage is safe (no serve-side effect) but use POST parameters (to avoid any URL's length issue), then should it be forbidden to call it using GET? Or should each page have some kind of "marker" telling it's safe or unsafe, and forbid GET only on unsafe ones?

First leads to some refactoring here and there to have GET only and POST only pages (and no more "mix"), while second leads to potentially forgotten pages (old ones, and upcoming ones by new developers).

I read the related post "Should I prevent sending of GET requests for urls that are normally operated with POST request?" but that question was for unsafe  POST, that obviously must forbid GET. Here, it's about how to globally handle {safe POST that could be called by GET + safe GET + unsafe POST that must not be GET callable}.

The distinction between GET and POST isn't just about safety. In terms of REST (the principle underlying HTTP), the GET method is a "retrieve the information specified in the URL" operation while POST is a "do something to the resource named by the URL" or sometimes "do the operation named by the URL" operation.

If your operation is safe but is not an information retrieval, then it is semantically incorrect to use a GET operation. If your information retrieval requires a query that doesn't fit into the URL length limit, then you probably need to structure your data better so your queries should be less complex. Your clients would appreciate not having to shuffle around a complex data structure just to retrieve the information they need.

Having the same resource operated on by multiple HTTP methods (a "mix") is very common and recommended in REST. Each method generally does different things to the resource, for example you might have an API where you have PUT /transaction/1 creates or updates an uncommitted transaction, PATCH /transaction/1 schedules additional actions to an uncommitted transaction, while POST /transaction/1 executes the transaction and marks it as committed, and GET /transaction/1 to retrieve the transaction detail.

There are many cases though where not all methods make sense in a resource. In that case, you would probably want to issue an HTTP 405 Method Not Allowed response.

  Should I forbid GET for non-side effect POST by default?

Generally, you don't want to. That you even think about doing so usually indicates that you might have a design smell or you might have a non-REST API.


Is it possible to prevent an attacker from capturing my WI-FI handshake on WPA-2 AES? For quite a while I've been experimentally hacking wireless routers by capturing handshakes and Decrypting them using oclHashcat on my computer. even the most complicated passwords won't take longer than 10 days with powerful GPUs available these days and also Wireless networks based on Radius server are so vulnerable to such attacks.

Is there any way to prevent an attacker from even capturing my WI-FI WPA-2 AES handshake and secure my wireless network against this attack?

No, it's not possible to prevent someone from capturing the handshake.

A properly implemented password with enough entropy can withstand even a very well funded attacker. The example hash rates given for the highest end machine are still only about 1 million hashes a second on a machine with 8 GPUs.  In a year you could do 1,000,000*60*60*24*365=3*10^13 passwords, or about 44 bits.  If you really want to be secure, generate a random 128 bit password, and print it on your router.  This will be secure from any brute force attempt, though it won't save you from rubber hose cryptanalysis.


"Must have" and "Preferred Cipher" suites terminology I have received the following advise to set cipher suites to suitably mitigate Beast attack on a newly setup Apache HTTPD server.

    Preferred ciphers: RC4-SHA, RC4-MD5
    Must Have Ciphers: AES256-SHA, AES128-SHA, DES-CBC3-SHA, RC4-SHA, RC4-MD5

I want to confirm my understanding of the differences between "preferred ciphers" and "must-have ciphers". My queries are:

Is the advise stating that the server should support the following ciphers in this order?

1. RC4-SHA
2. RC4-MD5
2. AES256-SHA
3. AES128-SHA
4. DES-CBC3-SHA

Should the advice translate to the following code for Apache mod_ssl?

SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:RC4-MD5:AES256-SHA:AES128-SHA:DES-CBC3-SHA

Shouldn't the advise really state:

Preferred ciphers: RC4-SHA, RC4-MD5, AES256-SHA, AES128-SHA, DES-CBC3-SHA
Must Have Ciphers: AES256-SHA, AES128-SHA, DES-CBC3-SHA, RC4-SHA, RC4-MD5

OR

Preferred & Must have ciphers: RC4-SHA, RC4-MD5, AES256-SHA, AES128-SHA, DES-CBC3-SHA

Are "preferred cipher" and "must have cipher" terms common terminology for expressing cipher suites in security world?

Thanks,

John

BEAST attack basically works on CBC mode block ciphers like AES and 3DES in this case. RC4 is a stream cipher, so it is immune to the BEAST and similar attacks, but you should know that RC4 starts to be considered broken and modern browser mitigate BEAST and similar attacks:

https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what

Is BEAST really fixed in all modern browsers?

I agree that the wording of the advice is confusing, but your conclusions are basically correct:

Yes, if you don't want to prefer block ciphers but still want to support them this configuration is acceptable, since it prefers stream ciphers over block ciphers and places the stronger suites in higher positions.
The configuration seems correct. You can verify your cipher-spec string with the following command:

$ openssl ciphers -v 'RC4-SHA:RC4-MD5:AES256-SHA:AES128-SHA:DES-CBC3-SHA'
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1

I think the best way would be to name the cipher suites to be supported and then define a preferable order among them. We don't really talk about two lists but a list and an ordering.
No, I don't think these terms are common


How Aircrack reliable is for decrypting password? other alternative? I'm testing over a Handshake captured file I have (handshake.cap) launching aircrack attacks against it with a lot of dictionaries and bruteforce to decrypt its password, but I don't have a strong processing capacity and bruteforce is not an option.

Is there any alternative to decrypt the password? It seems the password is not in any dictionary.

Yes, you have other alternatives. Aircrack only support dictionary and bruteforce attacks but you can convert the file into other format to be used with another tool. I can recommend to you to use hashcat.

To convert a captured file to hashcat format you must do: aircrack-ng /path/to/handshake.cap -J /path/to/converted_file -b 00:11:22:33:44:55. Of course you must put your paths and the BSSID of the network you want to recover the password. The -J parameter is to convert the file from one format to hashcat format.

Then, once the file is in hascat format, there is a new world of possibilities. Here is a link to the Hashcat's page. Now you can use GPU which is more powerful than CPU to bruteforce.
But even if is not an option for you, you can use for example rule based attacks with hashcat. Rule based attacks combine words in dictionary with some rules. This rules depend of the rule file you use.

Some of them exchange letters, other add prefixes, suffixes. Others tranform the words in l337, or whatever. The rule files creators are so imaginative! Some of them combine a lot of them and can be complicated.

The point is to try to get the password "playing" with these rules and the dictionary files and believe me... it works so many times!

So many pentesting Linux distros already have rule files to be used on rule based attacks like this I'm propossing you. For example, in Kali Linux you have a lot of them in the /usr/share/hashcat/rules folder.

Hashcat has changed recently its way to work. Before version 3, there were different executable files to use CPU and GPU. Now, with hashcat v3, there is only one executable for all and only change the parameters to select what you want to do (CPU, GPU).

Let's assume you want to use CPU because you said you haven't strong processor capacity.

Command for hashcat < 3: hashcat -m 2500 -a 0 "/path/to/your/converted_file" "/path/to/your/dictionary_file" -r "/path/to/your/rules_fie" -o "/path/to/your/pot_file"

Command for hashcat >= 3: hashcat -m 2500 -a 0 "/path/to/your/converted_file" "/path/to/your/dictionary_file" -r "/path/to/your/rules_fie" -o "/path/to/your/pot_file" -D 1 --force

Maybe you can "pivot" from hashcat format to other format to use another tool, but I think with hashcat you have all you need. Good luck!


How can someone spoof texts with my phone number? A dear friend of mine in the U.S. recently told me that she had been quite hurt by the unkind texts I had sent her after the Holidays.

I do not have a texting mobile phone, nor do I do texting from my landline at home. She claims it came from my number and under my name to her mobile phone in the States. I have lived in Europe for 3 years with no texting ability from here. How can this happen?

To answer the question given in the title:

  How can someone spoof texts with my phone number?

First, it is important to understand that one of the central systems phone providers use to communicate and to send information from one carrier to another (SS7) is based on trust. The system was developed in a time when all operators would trust the information received from others.

This gives way to sending information into a network with false content, something that is very easy, given that you have access to a SS7 gateway into the network. A carrier can simply tell another that the message is from a specific number, and this will be accepted.

More practically for the average Joe is to use internet services that give you the option to enter the desired sender's number, such as this. You are then able to send SMS messages pretending to be someone else.


Is restricting a Google API key for an Android app useless? According to Google, one can add the SHA-1 certificate fingerprint and the name of the package in the Google Developers Console to restrict the usage of his API key to his Android app, so that developers can make sure that their API keys are not being used by other clients than theirs.
According to this and this, programmers should simply add the SHA-1 fingerprint and the package name to their HTTPS-request headers in order for Google to be able to verify that the request comes from the "authorized" app and consequently serve it.
But since the SHA-1 fingerprint and the the package name are publicly known, then anyone else can also very simply add them to his HTTPS-request header and let his program very easily bypass the restriction and verify himself by Google as the "authorized" app!
Therefore, I do not understand the usefulness of this kind of restrictions which are based on infos that are publicly known!

As domenukk stated in his comment, the Google API key restriction prevents other users from packaging your API key in their app. It is simply a way for Google to ensure that the API calls it is receiving are coming from an application that was packaged by the developer who added said key to his Google API account.
However, as you rightly pointed out, it is easy to circumvent. For example, this answer on SO shows how to build a request using any Android Google API key. So the matter of circumventing the restriction is rather trivial.
However, the benefit is in the cost involved for an attacker. A similar question was asked for HTTP referrers, so I will just quote the relevant part to your question (just replace referrer header with SHA1 fingerprint):

So, just because a malicious agent could copy the referrer header, they may not have the time or inclination to do so. Think of a valid referrer header like a concert wristband. Can you forge them, or sneak around the guard checking wristbands? Sure you can, but it doesn't make the band useless.
It raises the cost for the attacker.


Should I update my SHA-1 certificates? If so, how? Q: Should I update my SHA-1 certificates?  If so, how?

Recently I noticed the "https:" has a red strike-through and warning in Chrome, but only on certain websites.  Apparently this has been attributed to Google sunsetting SHA-1.  A few comments here suggest getting the certificate re-issued in SHA-2.

How do I get the certificate re-issued?  Without much knowledge in web security, I'd prefer to hear it from a trusted source (here), as opposed to following instructions from some website I don't know I can trust.

Edit:

Take Wikipedia: clicking the https in chrome, I see I'm using SHA-1 via a certificate GlobalSign Organization. But shaaaaaaaaaaaaa.com/check/wikipedia.org suggests that Wikipedia does have an SHA-2 certificate, so I don't think this is an issue with Wikipedia. How do I use the other?

I have verified the browsers are up to date, and cache is cleared, Firefox is using the same certificate as Chrome. However, the current certificate used is signed by GlobalSign, the one on the shaaaa website is signed by SSL Labs.

As a user/client,  you can revoke a certificate   only if it contains the same subject name as the certificate presented for authentication. You can do that  using the revocation form provided in the end-entities page. Otherwise only if you are a CA administrator or a Certificate Manager you can do it by yourself.

Implement Role-Based Administration:

CA administrator: Configure and maintain the CA. This is a CA role and includes the ability to assign all other CA roles and renew the CA certificate. These permissions are assigned by using the Certification Authority snap-in.
Certificate manager:Approve certificate enrollment and revocation requests. This is a CA role. This role is sometimes referred to as CA officer. These permissions are assigned by using the Certification Authority snap-in.

Your CA can reissue your certificate with SHA-2 signature because, as mentioned in your link, SHA-1's use on the Internet has been deprecated since 2011 and:

  HTTPS sites whose certificate chains use SHA-1 and are valid past 1
  January 2017 will no longer appear to be fully trustworthy in Chrome’s
  user interface.


What does a Yadis / XRDS discovery session "look like" to the end user? How does it work? Is it relevant? I can't wrap my head around how Yadis / XRDS would be used by a typical end user, or how it works so transparently? Considering that this technology isn't adopted by mainstream IDPs that makes me think this is an abandoned technology (last wiki edit was 2008).

  How does Yadis / XRDS work, and is it applicable or relevant today?

If you login to a website such as security.stackexchange.com via OpenID, the website will use yadis/xrds to discover the identity provider based on the information entered by the user.

The website may need to redirect the user to the discovered login page of the identity provider, unless he is already logged into his identity provider and has told it to automatically accept login requests from the website. The yadis/xrds-discovery itself is not visible to the user, but of course he will end up at the right website (if everyone plays nice and does not attempt to phish for accounts)

In the end the website will use the discovered information to verify the identity and may retrieve additional information about the user.

You can find more information in the OpenID specification.


Are there risks of using the same OpenID provider for sites with different security levels? I always use the same OpenID provider (Google, with a strong unique pw and 2-factor auth) in every site that supports it, without thinking twice. It's my understanding that, as long as the provider is safe, it doesn't matter if one or more of these sites get compromised, the rest of them will remain safe.

However, one comment in another question put me in doubt:

  One part of the issue is that you "lose" control of your users' identities, so you might be exposing your data (...). However, typically a user will use his OpenId for several sites, some of lower security, which might potentially put his identity on the higher-security site at risk. (A question of trust boundaries and attack surface). BUT, if he wants to mix identity between secure- and not-so-much sites, that could be his choice.

I've been reading about user-centric and enterprise-centric identities and some related concepts, but couldn't quite understand how this can happen. Afterall, each Relying Party only trust the OpenID Provider, not necessarily one another. Activity in one of them will not be endorsed by the other, even if it reports it as linked to the same OpenID account. Besides, sensitive info in a RP won't necessarily find its way back to the OP, much less become available to the remaining RPs.

And anyway, a site (or collection of related sites) can create its own "persona" independently of the method of authentication. StackExchange, for instance, have a single network profile that centralizes all actions from the same user across its many sites, and at the same time allows each user to authenticate to the same account through many OpenID providers (if either of the providers are compromised, then of course the user account will be at risk, but not if all providers are safe and some other relying party - linked to any of them - misbehaves).

Am I missing something? Should I use different providers for sites that I care more or less, or is ok to keep using a single one for everything?

P.S. When I first read "I Just Logged In As You" and its followup I thought it was a problem with OpenID, but after a careful reading I understood that the actual problem Jeff faced was password reuse, and other than that his provider account would still be safe. Is that correct, or is there really a possibility that a compromised Relying Party can end up interfering with the OpenID Provider?

The risk here is the online persona itself and what would result in social engineering attacks.  Let's say that you use google as the openid authenticator and have linked it to the stack exchange sites along with a collection of other sites.  Prior to this, you may have used the same username and everything else across all sites but it was all a loose association which people would not use to trust that "mgibsonbr" is actually you.  Well now people can see on sites such as stack exchange, reddit and shodanhq, mgibsonbr is linked directly to your gmail account and they trust that they are actually talking to you.

Now lets say someone compromises stack exchange and can impersonate any user.  Big deal right?  all they can do is ask or answer questions and people will think that you didn't understand what rm -rf / would do.  Well what if they started applying for jobs as you on the Careers 2.0 site?  Employers are going to believe that they're actually speaking with you because the Careers 2.0 site is directly linked to your email address.  Maybe they'll even get a job and be employed as you at some company.  Or maybe another site you linked to your openid allowed you to apply for credit cards.  Now someone has credit cards in your name.

The idea is that you would not want to link your open id with any site where posing as you could do any real damage.


What can a hacker do if I publish my email id and password but have 2FA on all of my accounts? I have 2FA on ALL of my accounts. But my password was leaked in 7 breaches.
Unfortunately I have used the same password for most of the accounts.

Is it possible for him/her to bypass the 2FA?

This depends on the kind of 2FA and of the policies of the service providers. If 2FA is strictly bound to a dedicated physical device (U2F token or similar) it should be kind of impossible to bypass it directly unless the attacker gets hold of this physical device. If 2FA is instead only implemented using an app on a mobile phone the attacker might additionally try to target the phone itself. If 2FA is SMS based there are even more attack vectors.

It also depends is the second factor is bound to the domain you visit (as in WebAuthn) or not (SMS and others). In the second case the attacker might trick you into entering the token into some look-a-like phishing site instead of the real one.

And finally it depends on what processes are implemented at the service provider in case of lost 2FA access. For example if there are only some (often easy to guess) security questions to answer in order to disable 2FA or change the phone number for SMS 2FA then it does not help a lot if the client still owns the original 2FA.


How does RSACryptoServiceProvider generate keys The documentation for the constructor for RSACryptoServiceProvider states

"If no default key is found, a new key is created.
This constructor creates an Exchange key pair suitable to encrypt session keys so that they can be safely stored and exchanged with other users. The generated key corresponds to a key generated using the AT_KEYEXCHANGE value used in the unmanaged Microsoft Cryptographic API (CAPI)."

This leaves some questions;

How is this key generated, I think RSA keys require a large prime, but I don't think .net keeps a large list of primes available.  Nor does the constructor spend the time to find new primes.
When is a default key available?
How secure are the keys generated by this constructor?

RSACryptoServiceProvider, like most system classes in .NET, is a thin wrapper around the older Win32 implementation (an API which was meant to be used with C or C++ -- or even Pascal, if we really dig deep). See CryptAcquireContext(). In .NET terminology, this is called "unmanaged code".

Generating a RSA key pair involves producing new random prime numbers. Knowledge of these primes is the private key, so we strongly hope that the Microsoft implementation does not simply uses a fixed list of pre-generated primes ! Conceptually, this generation is simple: produce sequences of random bits of the right size, and repeat until you find one that is prime.

In more details, if you want a 2048-bit RSA key, you will need two 1024-bit primes whose product is a 2048-bit integer. This goes that way:

Generate a sequence of 1024 random bits, such that the first two bits and the last one are equal to 1; the 1021 other bits are obtained from a strong random source (in Win32, this is CryptGenRandom() -- RNGCryptoServiceProvider is the .NET wrapper).
Interpret the 1024 bits as a big integer p. Since we set the first two bits to 1, and there are 1024 bits, then the integer is greater than 3×21022 and less than 4×21022; since the last bit is also 1, the integer is odd.
Verify that p-1 is not a multiple of the chosen RSA public exponent. Traditional exponent is 65537. There is a probability 1/65537 that p-1 is a multiple of 65537; if that is again, go back to step 1 to generate another candidate.
Test the integer p for primality. There are several methods for that; usually, Miller-Rabin primality test is used. If p is not found to be prime, go back to step 1 to generate another prime. For a 1024-bit p that we took care to make odd, you can expect to test an average of about 500 candidates before finding a prime.
Once you have generated a random prime p, do that again to get another one, which we will call q.
The modulus will be n = pq. The public exponent is the chosen e (65537 in the example above). The private exponent d and the other RSA private key components are computed algebraically from p, q and e. Thanks to the way p and q were generated (two top bits equal to 1), it is guaranteed that n will have size 2048 bits, not 2047.

The whole API is barely usable. The concept of the "default key" is aberrant; you cannot decently rely on it in any protocol, since you do not control neither its storage nor its life cycle. Also, that default key will have length 1024 bits, which is a bit too short for today's technology. If you want to obtain and use a RSA key, you should ask for its generation explicitly, and certainly not register it as a "default" that any other application may use or possible modify, export, publish or whatever.

It is also badly underspecified. CryptAcquireContext() accepts multiple options that impacts how the key, if any, is generated and stored; the documentation for RSACryptoServiceProvider does not tell which options are used. If you want to know what really happens under the hood, you have to delve into the source code.

The bottom-line is that the RSACryptoServiceProvider constructor will generate new primes, for a 1024-bit RSA modulus (hence 512-bit primes), but it will try to keep around a "default key" so that it will do that only once even if you call it repeatedly. Note that producing a new 1024-bit RSA key takes only a fraction of a second with a modern PC.


Is it safe to pay bills over satellite internet? We bought a house. We need internet for basic research, email and paying bills, but there is no internet... Even a dedicated hotspot will not give us a stable connection. We are planning to get satellite internet.

Is it safe to pay bills and access accounts through this? Specifically, should we be be concerned that someone can just snag our signal out of the air and steal our information? I know anything is possible, but is it likely? My wife is concerned and I need some answers to assure her...

Keep in mind we are out in the middle of nowhere, there is not any other service providers out here and our cells have spotty reception...

Satellite is not safe. Neither is cell data, wifi, or cable Internet. None of it is safe at the layer that you are talking. And that's not the layer that needs to be safe.

It's the data that goes over satellite (or wifi, cell, or cable modems) that needs to be secured. That's why we have HTTPS, that little green lock on your browser (it's gone now on most browsers and just grey now because HTTPS is pretty much everywhere).

So your choice of internet provider's media is not what's important in your situation. It's whether you use encrypted sites over that media.


Can someone please explain RBAC to me? From http://msdn.microsoft.com/en-us/library/jj709705.aspx

In contrast to the DAC model, which is oriented around objects, the AzMan RBAC model attempts to orient the common administrative experience around user roles. Rather than assigning permissions to objects, an AzMan RBAC framework enables applications to present administrators with a management experience more aligned with the organizational structure of a company. AzMan RBAC provides a central object—a role—that a user is assigned to perform a particular job or application function. Ideally, an RBAC application is designed such that the administrator requires less knowledge of the object storage structure. This approach can be used if the RBAC application provides a simplifying abstraction into resource collections referred to as scopes.

Can someone please explain to me how this is any different at all from user/group ACLs?

e.g.

Say I want managers to have read access to /mnt/network_performance_reports, sysadmins to have full read/write access, and everyone else to have no access.

I would think that (on Linux with POSIX ACLs, I don't really know Windows) I could

set a default ACL on /mnt so everything under it is effectively chmod 0700 (directories) or 0600 (files).
create a sysadmins group and set up a read/write default ACL for sysadmins
create a managers group and set up a read-only default ACL for managers

That's not exactly easy to manage (not centralized, blech!) but it does the same thing, doesn't it? I don't think I'm quite understanding the concept.

When people talk about RBAC in operating systems, are they effectively talking about a layer of abstraction on top of MAC/DAC systems to make management of those easier for large organizations? Or are they talking about something that is different internally; i.e. is associated with completely different methods and data structures in the the OS kernel?

First, I think we should clarify vocabulary. DAC means discretionary access control, which means someone (to be defined) can decide who accesses what within the system, when MAC, mandatory access control, tends to relate to systems where access cannot be given within the system.
In my understanding, neither DAC nor MAC implies a specific implementation.

Concerning RBAC in the UNIX world, IBM has a good explanation on why this is important: http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.security/rbac.htm?lang=en. The AIX RBAC implementation implements a partition of the set of all root accesses and allows specific roles to have specific admin access (on the network, on the passwords, and so on)

Your example with sysadmins and managers is a good one although limited to the user space and file access.

So regarding your last question about the place of an RBAC UNIX implementation  (layer or different internals), it seems it largely depends on what access we're talking about.

If file access is concerned, RBAC can be implemented with existing functions, although ressources a role can access are not centrally managed as you mentioned. A layer of abstraction could deal with that.
if root accesses are to be divided in many accesses (The AIX RBAC implementation), then I guess some internal work is needed with new methods and data structures in the OS kernel.

Hope this helps,
Regards,


Does Chrome's password manager store plaintext passwords in their databases? Chrome's password manager allows for users to view their saved passwords on passwords.google.com. The saved passwords can be viewed on different devices as long as the user logs into their Google account. So, these passwords must be stored in a Google database. Is it known as to whether the passwords are encrypted in this database, so that Google wouldn't be able to know what your account passwords are?

If you can see a password (in plain text), it cannot have been hashed. The definition of hashing is that this process is irreversible. An alternative, less secure way, to store passwords is to encrypt them. The problem is that you can decrypt passwords, but depending on your use case, this could be a feature and not a bug.

How Google Chrome saves your passwords depends on whether you want to store and use them across devices. When synchronization is turned on for passwords in Google Chrome, your passwords are saved to your Google Account. Otherwise, your passwords are only stored on Google Chrome on your computer.

Not hashing passwords is not a best security practice, but depending on your use case encryption could be acceptable in combination with other security measurements to prevent unauthorized access.

Learn more about storing passwords on Google Chrome on this page.


Can I encrypt a file incrementally? Is there any way to encrypt a file incrementally?
The problem is that I receive a file a chunk at a time via Internet (it's a client-server application and I send byte arrays via a WCF service) and I don't know when the next chunk is going to arrive (if any) and what is it's size. Everything I know is that I can't store it into RAM, I immediately need to cypher it and append it to the previous chunks.

Constraints:

I can't impose a chunk size;
I would like (if possible) to decrypt the file like if it was encrypted as a single file;
I can't store the chunks without cyphering them;
I can't store the various chunk sizes nor store the chunks into different files;
I'm using an AES algorithm;
I can't change my job.

Any ideas or suggestions?

Yes.  Most symmetric-key encryption algorithms support a streaming mode, where you encrypt the message incrementally as it arrives.  This includes CTR mode, CBC mode, and most other modes.

Similarly, most message authentication codes (MACs) support a streaming mode of operation when generating the MAC.  On the other hand, when verifying a MAC, while you can process data in a streaming fashion, you cannot check whether the MAC is valid until you've processed all of the data, so you cannot act on the contents of any chunk until you've received them all and verified the MAC on the entire file is valid.

In your situation, there's another solution that's probably simpler: encrypt each chunk of data as soon as it arrives, and store all of the encrypted chunks.  When you want to decrypt, decrypt each chunk, then concatenate the results.  If you follow this approach, make sure to include a sequence number and the filename in each chunk, so that they cannot be re-ordered.  Also, make sure to use authenticated encryption (as always).  This approach is probably simpler and thus may be a better match for your needs.


Shadowsocks: Doesn't communication with just one server look suspicious to the GFW? From what I understand, Shadowsocks masks SOCKS5 traffic as HTTPS traffic, so that the GFW cannot detect it by packet inspection. Shadowsocks can be installed on my own server, naturally. For usage, I would establish a connection with a Shadowsocks client and point my browser's SOCKS5 configuration to a certain port on localhost. Now, all my traffic when browsing the web is exchanged between my PC and my server, via my ISP. And here I don't understand:

Doesn't it look suspicious to the GFW if an individual's daily Internet traffic is happening between his PC and just one server? Wouldn't it be trivial for the GFW to eliminate Shadowsocks connections by blocking IPs?

Possible? Sure! Will it be done? I doubt.

Unless your traffic is on the top chart, you are a small fish. And they don't have resources or people or willingness to pursue every single private VPN service out there, because there are more interesting things to pursue.

IPv6 addresses are plentiful and cheap this days. If you are concerned about being blocked, rent a VPS or two, with IPv6 addressing, and have shadowsocks listen on every address. Change to a random address at random intervals and you can conceal your VPN a little more.


Can I connect our network to the internet but only allow connections to certain servers? At work we have a network that is not connected to the internet however it is exposed to the outside work through USB drives and employees cell phones.  I'd like to connect our system to the internet to get automatic Symantec & windows updates.  Currently I have to update these manually which I don't have time to do as frequently as I'd like.  We also run some record management software that is diminished by not having access to the internet.

Is there any way for me to utilize a firewall to specify that our network is only allowed to connect to the Symantec live update server, the windows update server and our records management companies server and deny all other incoming and outgoing traffic?  If that is possible how hard (or how common) is it for someone to spoof that they are the Windows update server?

I realize that there is no system that is completely safe but my goal is to find a safe way to streamline keeping our software up to date (and possibly expand the capability of our computers) without having to constantly monitor the system.

We are running Windows Server 2003 with workstations running XP.  We have Symantec Endpoint 12.1 and currently have no hardware based firewall.

Limiting access to certain addresses

A firewall that connects your network to the Internet can do exactly this. You whitelist the IPs that you want, and default deny any other communications (in or out). I don't normally suggest going to a custom firewall (Linux OS on a computer that only does firewall and is used for nothing else) right away, but I think it may give you the simplicity and power that you need. The upside is that you might be able to use equipment you already have for this purpose, considering the throughput you suggest (providing it is not too old).

pfsense is highly regarded.

That said, you will have to write the firewall rules. So, it is not 'point-and-click', and requires a moderate level of skill, but totally doable.

Spoofing Windows Update

It is possible to spoof a software update site, but programs such as Windows Update and Symantec update verify the address it is connecting to, so the risk is very low.

EDIT

Oh, and I'm sure someone will point out, so I'll beat them to the punch: you are likely exposing your network to more security issues by allowing USB keys and personal electronics in your network than with a poorly configured firewall (given the right conditions). So, by limiting (eliminating) those things and having a good firewall, you will be miles ahead than where you are now.


Hashing password for secure storage (generating salt) I wanted to check if the following means of generating a hash for storage of a password was secure.

I have an username and password combo. In order to generate a secure hash, I am doing the following:

gen_password = SHA256(password + "my_site_name")

gen_salt = SHA256(username + password + "my_site_name")

hash = PBKDF2(gen_password, gen_salt, rounds)

Anyone see any weaknesses or problems with this approach? Generating and storing a salt is not an option, so I am hoping this method would work.

If anyone can offer improvements on this, that would be great!

Thanks.

The weakness in your system is intrinsic: there is no real salt. From your comments, I suppose that you cannot (for some contextual reason) store a randomly generated salt. So what you do amounts to, basically, use the pair "user+site" as salt.

Your various hashes are complex and some parts are useless: there is no need to input the password in so many places. You should strive for simplicity; complexity is your enemy. Still, you have to contend with idiosyncrasies of PBKDF2 (if you want to use that function), so the following should be as safe as you can be:

s = SHA-256(username + '|' + sitename)
p = SHA-256(password)
hash = PBKDF2(p, s, rounds)

Note that I use a '|' character as separator, and I assume that such a character does not appear in the site name (this is to avoid spurious collisions). The extra SHA-256 on the password itself is only to avoid an issue of PBKDF2, which is that it becomes twice slower when the password length exceeds the length of the underlying hash function (64 bytes for SHA-1 and SHA-256). If you are sure that your passwords will never exceed 64 bytes, then you can remove the second hash and use 'password' directly in PBKDF2.

Main remaining issue: if the user changes his password, the new password and the old password will use the same pseudo-salt. If an attacker can get both hash values, then he can try to break both for the cost of breaking only one. A similar problem occurs if you destroy a user account and then reuse the same user name. You cannot avoid this problem as long as you don't store a salt-like value (randomly generated) along with the hash values.

Improvements: you may want to change some parameters. For instance, if your server is a PC (64-bit, or at least a PC with SSE2 and using OpenSSL for the hash function implementation), you may want to make sure that PBKDF2 relies on SHA-512 instead of SHA-256 or SHA-1: SHA-512 will be efficient on your PC but make life harder for an attacker with a GPU (usual GPU are less comfortable with 64-bit integer types). You may also want to consider switching from PBKDF2 to Bcrypt, for the reasons exposed there.


Anonymizing data for applications I try to design a system which reads events comming from devices, stores them and exposes API to various applications. Originally I wanted to introduce a module Id translator, so I would store only anonymous device id in a database. It would be then protected from unauthorized data harvesting.

Then I wanted to have another module called Roles Registry responsible for handling API permissions for each application. I had an idea in mind that application wishing to work with concrete device id would need different permission than application using anonymous identifiers.

Another module Event Access API would be single entry point for data access and it would evaluate if the API permission was granted to the application.

But as I start to think of it I think that this concept is weak. It is hard to explain because myriads What if questions arrive in my mind, I consider some as probable, I reject others etc. I need to clearly specify my requirements and find consequences.

I want

anonymous database so neither admin can search for data of specific event id
search by concrete device id would require different permission set than anonymous search by other criteria

But I see main problem with returned data:

If API returns artificial id then caller can save it and then he can use anonymous API next time
If API returns real device id then API needs access to Id Translator database (really big data, fast access) and then admin can easily match anonymous data with concrete device id

It may be a unsolvable and I shall just skip the first requirement (admin protection).

I would be gratefull for

Any insights how to design such system and API
What is the best practice?
Shall data be anonymized in database?
Shall API return anonymous db identifier or real device id?

Thanks.

I was reading about the anonymizeation problem just the other day.  As it happens, the first edition of what I was reading is on line, at
https://www.cl.cam.ac.uk/~rja14/Papers/

This is from Ross Anderson at Cambridge, who is well-known in the community. You want one of the Security Engineering chapters, starting at SE-01.pdf, but the're other stuff there in his blog.


PCI DSS placement of puppet (or chef) server? I'm puzzled as to whether I am allowed to set up a puppet server in a PCI DSS environment, and if I am, where should it be located?

I was planning on installing it on gateway, and all the hosts would connect to gateway https/8140 to pick up node manifests.

Would this violate PCI DSS requirements, and if it would, is there a better place to put it? Maybe DMZ?

What are your experiences Puppet/Chef/Salt in PCI DSS environments?

Thanks

I worked for a QSA company for 2 years, so here is one ex-assessor vision of your case.

It is absolutely fine to use configuration management (CM) tools from the PCI DSS perspective. In short, to be OK with the standard compliance you must make this system PCI DSS compliant itself and align your configuration management and support processes with PCI DSS requirements.

First of all, deal with the PCI DSS scope. While tools such as Puppet/Chef are not directly involved in payment card data processing, they are affecting the security of such system components. It will not be considered a part of cardholder data environment (CDE), so it is not required to sit within isolated network segment. Any Puppet/Chef service dependencies that affect its own security will also be in scope of PCI DSS review. These may include: AV server, log server, authentication , version control, package repository servers and so on. So, in case you have such infrastructure within PCI DSS scope, it is a good idea to reuse it (for example, forwarding logs to already-in-PCI-scope log server).

There are generally two recommended patterns when you incorporate CM tools into your environment:

Install self-contained server within CDE and use only for the purposes of managing PCI-related system components. This way, you are minimizing impact to your existing PCI DSS scope but losing flexibility.
Use multiserver architecture and install some part of it within CDE. This way, you get more flexibility, but some systems from your “regular” non-PCI network will be in scope as well.

In any case, you should work closely with your QSA to determine if your intended scope is correctly defined and no important systems left behind.

Once you understand what changes to PCI DSS scope will be made by incorporating configuration management tools, you may plan how you’d implement technical and procedural PCI requirements for this changed scope. I will not describe process here, since it is too lengthy and is not different from what you already should be doing with your existing infrastructure anyway.

One important point that I want to note though: introducing CM tools usually greatly impacts established change management routines. Per requirements listed in clause 6.4, there are a lot of tasks one should be doing when applying changes. This means literally anything you do with the whole your CM system must be planned/tested/reviewed/approved in PCI-prescribed way. And that’s the reason why a lot of DevOps shops end up using completely isolated CM system to manage PCIDSS-related systems. Anyway, make sure you have your change management procedures updated.

I hope this helps – it is hard to address this issue and not write a lengthy paper with a lot of “if else” conditionals.


Is a MitM (Man in the Middle) attack by definition an altered or injected communication on an encrypted communication? If so, what is it called when someone alters or interjects into un-encrypted communications? Is that email spoofing? How is it resolved?

End users probably are more concerned with the fast resolution of the current disruption to their work than with the technical prevention.

How would an account holder even know to speak with a security person since the recipient of a negative injected message is unlikely to respond or be open to printing copies for comparison with sent messages.

(Joe says "I love cats". The recipient receives the message "I hate cats", becomes angry and doesn't respond. Joe then says "Do you want me to babysit your kitten?". Recipient responds with "Piss Off". Joe says "You piss off!!!!!")
The MitM is buried in the middle of several other authentic messages.

How would you know?

Short answer - no, man-in-the-middle attacks are not necessarily confined to encrypted communications.

Also, in many cases MITM on encrypted connections is aimed at actively intercepting/eavesdropping on messages, rather than injection. One example are some Intrusion Prevention Systems (IPS) (e.g. PaloAlto do it for SSH) that need to perform MITM in order to inspect traffic content, which otherwise would pass through the IPS w/o being fully examined.

On your second question of verifying the authenticity of a message, one does not have to exchange messages over an encrypted medium, but can use methods such as digitally signing messages (for example, using PKI) - the message can be sent in plain text, and the attached message fingerprint (cryptographic signature) can prove its authenticity.


How do you trust your developer to be competent security wise? Let's say that you want to hire a developer to deal with a part of a project in which you don't have any expertise.

How can you have confidence that he knows what he's doing since you have no idea what he's doing?

I know that the question might be reduced to "How to trust your developer" but I find the security aspect of it way more complicated because it's impossible to attest what is secure or not. For other things, you can quickly look at what the developer produced and you get an idea of his skills. But, for the security aspect, what do you look at?

To trust someone, you need to establish a basis for trust. That might be knowing about past work, questioning them about their ideology and morals and so on. There is no easy route to trust.

To trust their professional skills is no different. Have they done similar work? Who recommends them? How do they act online and in the real world? Do they exhibit qualities of trust everywhere? Do they have a track record?

But there is a slightly different question that would be a much better one for this forum.

"How can I trust code that a developer has written if I don't understand it?"

Again, there are no magic bullets but there are things you can do to reduce any risks:

Do you trust the person? e.g. the first question. If they have a track record of trust, that's a good sign.
Make an attempt to understand the code - well written code will be modular and it should be relatively easy to understand when read, even by non-programmers - if it is important and you really have nobody available to make sense of it, get someone in.

Incidentally, if someone has written code for you and it is incomprehensible then there is a pretty good likelihood that they've done a bad job.
Use tools to analyse the code for common errors and flaws.

You should also be making sure that you specify the requirements correctly. If your spec to any programmer doesn't make clear what quality criteria you need - regarding security, readability and documentation for example - you only have yourself to blame if it all goes horribly wrong.


Account information gathering on subnet device I have a cybersecurity test coming up. We have a practice test, but no solutions. One question involves being given a fresh Kali VM and a target IP on our subnet, and having to discover as many username/password combinations on the device as we can.

I have no idea how to even begin this process. Would someone mind giving me a general outline or the Kali tools involved in finding usernames and passwords on a computer in your subnet? I learned a little about nmap scanning, but don't know if that's even relevant to this question.

It also says that for each owned account, credit will be based on the most privileged group to which it belongs, then lists 3 group names along with point values. Does this mean that the process will be different depending on the group? How should I interpret this?

Any help or suggestions on where to start is greatly appreciated!

Your questions are fun ^^

Start with nmap, look for cheatsheats; n0where.net has all kinds of fun stuff to read about.

Maybe follow up with metasploit, there is a another vuln scanner I used to use quite often...I'll have to do some digging but, had pretty good luck with it. Its been about a year since I've written a detailed security assessment so, I'm a little rusty.

Again low hanging fruit. If you can find some vulnerability that allows you to gain access, someone has probably already written a script that does most of the work for you. You just need to identify weak points of your target. Try some vulnhub targets at home (probably what you guys are using).

If there is a web server built into whatever image (I presume) you guys are attacking take all of the usable information you can from that. Like look for company directory page, index, something like that and create usernames from it. I would make a list of last name first initial and first initial last name. Same thing if there is an ftp server.

Read up on John.

Make yourself a password list and those usernames you created, put them in the password list. I would put the company name in there too.

Get yourself a user list off of the target system. Put those in the password list.

https://askubuntu.com/questions/410244/a-command-to-list-all-users-and-how-to-add-delete-modify-users

http://www.cyberciti.biz/faq/linux-list-users-command/

I wouldn't start out trying to crack passwords from the get go. It is a long process sometimes. Try to focus on vulnerabilities, privilege escalation, pivoting.

Hope that helps or at least points you in the right direction.


What to do about "approved" direct banking MITM sites like sofort.com? Brussels Airlines allows several payment types, only two of which are free: Maestro and Sofort Banking:

The second option was new to me, but direct debit is usually a free and practical way to pay: The request is forwarded to the bank web site, I fill in my details as if I were logging in, and the bank returns me to the vendor site with confirmation. However, in this case sofort.com wanted me to put my bank login details on their site! Username, password, one-time pad, everything!

After all of us effectively signed a "don't ever disclose your login details to anybody else under any circumstances, or else" agreement with our banks, how is this possible? And is there anything end-users can do except voting with their wallets? In this case, Brussels Airlines tickets can be had from for example Skyscanner, which does not use sofort.com and has free payments for many more card types, but what if it becomes standard?

For the record, the site is using a verified, valid, "strong encryption" (at least according to Firefox) certificate.

Another write-up about Austrian Airlines also using sofort.com.

After all of us effectively signed a "don't ever disclose your login details to anybody else under any circumstances, or else" agreement with our banks, how is this possible?

Sofort AG is a german company, so I'll focus on Germany: There was an antitrust proceeding, and as a result of it, most banks changed their terms and conditions to allow this (at least according to Wikipedia). It doesn't seem that the proceeding actually resulted in new laws though.

The european Payment Services Directive is currently being updated, and would then also cover third party payment providers (TPPs), so as I understand it, it would then also regulate Sofortüberweisung (the correct name for a service like this seems to be Payment Initiation Services). See also this interpretation here in English.

  is there anything end-users can do except voting with their wallets?

Well, you can lobby politicians, write news articles, search for and expose security flaws, etc. Or you can hope that there are valid alternatives and use them instead.

Security

The implied question here seems to be if this is secure or not.

it adds an additional company which can screw up, and thus reduces security (for no or few benefits).
you have to trust the company (in this case Sofort AG), as they could also just take all your money if they wanted to (but this is the case with a lot of payment options, paypal for example allows any shop to withdraw a random amount of money).
it might increase inexperienced users willingness to enter their password ("I did this so many times, and never did something bad happen before") and thus increase the success and amount of phishing attacks.


The risk to Tor exit nodes I'm asking a couple of Tor questions today (they're unrelated), and one of which (I'm hoping it's a simple one) is that my understanding is that all requests will be delivered to a server from an exit node. Despite the fact the request has been encrypted and pushed through an arbitrary amount of nodes before it gets there, is the exit node now not the one seemingly responsible for any malicious activity?

E.g. an injection attack is made as part of a web request, and somebody decides to trace the apparent origin of that request - surely the exit node is now the node under investigation/suspicion?

If, for example, I chose to navigate via Tor for a totally legitimate/ethical task, there is a real possibility (if not a probability) that traffic appearing to come from my IP was part of something totally illegitimate. An attack, or worse. Surely, at some point, in the history of Tor, somebody must have been contacted by law enforcement regarding traffic apparently originating from an IP they had? And if not, why?

is the exit node now not the one seemingly responsible for any malicious activity?

Correct, the traffic appears to be coming from the exit node.

there is a real possibility (if not a probability) that traffic appearing to come from my IP was part of something totally illegitimate.

As a normal Tor user you are never an exit node. You are only a middle relay between other nodes. So all traffic from and to your IP is encrypted and your IP would never show up in any server logs of the clearnet.

Surely, at some point, in the history of Tor, somebody must have been contacted by law enforcement regarding traffic apparently originating from an IP they had?

Yes, that occasionally happens. But the Tor network keeps a history of all the IP addresses that were exit nodes at some point. For example, you can use ExoneraTor to check for a particular IP at a particular date. So law enforcement will be able to recognize that an IP involved in an illegal activity was a Tor exit node and searching their home would probably not make much sense (although it can still happen).
That's why the EFF discourages running an exit node from your home in the FAQ for relay operators:

Should I run an exit relay from my home?
No. If law enforcement becomes interested in traffic from your exit relay, it's possible that officers will seize your computer. For that reason, it's best not to run your exit relay in your home or using your home Internet connection.
Instead, consider running your exit relay in a commercial facility that is supportive of Tor. Have a separate IP address for your exit relay, and don't route your own traffic through it.


Why are there open ports on my home network router? It can be a security risk to have unwarranted open ports.

So I ran nmap 192.168.0.1 to investigate if I had open ports on my home network, it turns out, I do:

PORT      STATE SERVICE
53/tcp    open  domain
80/tcp    open  http
5431/tcp  open  park-agent
49163/tcp open  unknown

This concerned me. However, upon further reading, I have discovered that running nmap from my home desktop does not obtain the actual open ports, but rather ports which are accessible from my desktop on the local  network side; I'm interested in ports open to the Internet at large.

Therefore, I tethered my desktop to my phone Wi-Fi Hotspot and ran nmap again, this time I am outside of my local network, i.e. I am not connected to my home router provided by my ISP but rather connected to the Internet through my phone service provider. I ran nmap again, this time using the external IP Address of my home network. The output is as follows:

PORT     STATE  SERVICE
21/tcp   open   ftp
80/tcp   open   http
113/tcp  closed ident
443/tcp  open   https
1935/tcp open   rtmp
8080/tcp open   http-proxy

There are still numerous open ports, which I was not expecting, as I am not running any servers and simply use my home network for Internet browsing.

Given the answers here, I do not think I should have any open ports.

Why are these ports open to begin with? And should I be concerned/close them?

Edit: I have a single gateway device provided to me by my ISP. I have one desktop connected to this device. My ISP is Sky.

In general, you should close them if you have such capability and have no reason to allow incoming connections.

What you did not state, however, is what your home network looks like. Do you have a cable modem and external router, or single gateway device? or?  Who is your ISP?
 Depending on your ISP, you might be talking to an IP entity on their network or on your LAN.


How does Lastpass decrypt my mobile vault after restart with just the fingerprint? So my vault (on mobile device) is encrypted with my Master Password. Without the Master Password, the decryption cannot happen.

There is an option to enable Fingerprint Authentication on the mobile devices. Obviously that is only done after you have provided the Master Password, and your vault is now "unlocked" (decrypted) locally on the device.

However, even if I restart the mobile device, I can log back in with just the fingerprint. So how can it decrypt my vault after restart with just the fingerprint?

Does the "unlocked" vault mean it is stored unencrypted on device's permanent (not RAM) storage? Is the fingerprint is just a security-theater, as someone can bypass the app and access the (unencrypted) vault directly on device storage?

The mobile lastpass client stores your password in the device's key locker which, in theory, should only be accessible after you enter appropriate credentials. In this case fingerprint.

Of course, there is a massive difference between security on Android to iOS (in general anyway) and I'm not familiar with the Android implementations other than to say that many Android devices have no hardware based locker which potentially seriously restricts the level of security you could expect.

On iOS, this has been well tested and found to be very secure - hence the ongoing battle between Apple and the FBI.

When unlocked, the vault is maintained in memory. So in theory, it would be possible to gain access. However, it uses protected memory which should not be accessible to any other application. As iOS has a more secure and restricted base, this again is likely to be more secure there than on Android. Though perhaps an Android expert can give a more definitive answer.

The downside of securing lastpass with a fingerprint is that the USA's border control have decided that you can be compelled to provide a fingerprint but cannot be compelled to provide a password. This has been verified in the US courts.

When I travel to the USA, I remove all cloud services except those I don't care about. Certainly I uninstall lastpass and add it back later. That doesn't just apply to the USA of course.

Using a fingerprint is not just theatre but it certainly does reduce security. Not likely to be enough to worry most people though. Of course, I only use LastPass for less critical passwords. The most sensitive are kept in a separate vault accessed using a different cross-platform tool. That doesn't have fingerprint integration and I don't keep the vault open anyway unlike LastPass which I often have open.


Is it possible to add virus to an encrypted file? If an attacker has physical access to your computer, could he modify an encrypted file as such that when you move the file to another computer and decrypt it there this new computer which you intended to use to safely decrypt your file will be infected?

I'm interested if this is possible for

LUKS / truecrypt

Veracrypt

PLAIN dm-crypt

which are all implemented in zuluCrypt.

If that is not the case would it be possible with encrypted *.odt files?

For truecrypt and Veracrypt, I believe there is nothing stopping you from modifing the file and this is likely true for all FDE solutions.

However, it would be impossible to ensure the modified file decrypts into a virus, unless they somehow trick you into encrypting the virus with the same key or otherwise gain some additional knowledge.

It could be possible to embed the virus into the file non-encrypted and get it executed if there is some critical bug in your decryption software.


An email from gaia.bounces.google.com I received an email from gaia.bounces.google.com, supposedly from Google, which asked me to click on a link to check my security status.  Is this legitimate?  I searched with my Norton Safe Search but couldn't find this .com at all.

This Google help site tells you how to check for an authenticated message.

To quote:

  The message is authenticated if you see:

  "Mailed by" header with the domain name, like google.com.
  "Signed by" header with the sending domain.

  The message isn't authenticated if you see a question mark next to the sender's name. If you see this, be careful about replying or downloading any attachments.

  When an email isn't authenticated, that means Gmail doesn't know if the message is coming from the person who appears to be sending it.

What this translates to, is the following: if the message is authenticated, the sender that is displayed is really the person or system that sent the message.

That does not mean though, that every authenticated message that you receive from a person or system is a legitimate non-phishing message. The likelihood is however very much increased.

Because there are very little details in your question, here are two other questions that might help you:

for identifying phishing mails in general refer to this one
and also have a look at this one, because it could be a duplicate to yours.


Cheap to validate yet expensive to compute hashing algorithm I am looking for a hashing algorithm somewhat like bcrypt, except that I would like validation to be extremely cheap.

As an anti-spam measure I would like to require my clients spend say, half a second of compute time, before they submit information. I would like to assign them information to hash and then on my end quickly check that the information was hashed correctly. To protect myself from a DoS using something like bcrypt would not be feasible.

As it is an anti spam measure, I am not looking for perfection, the hashing algorithm can be weak.

Is there a name for such an algorithm? What could I use?

It's called a "proof of work" algorithm. The basic idea is you force the caller to do some extra work after creating the hash. You can use any hashing algorithm. Here's one simple form:

The client computes the hash of the data. (Say, it's 160 bits.)
The client creates a block containing the hash and the rest of the data all zeroes. (Say the block is 512 bits.)
The client computes the hash of this block.
If this final hash is below the target, the client submits the entire block it just hashed and is done.
The client increments the data in the block other than the hash and jumps to step 3.

When the server gets the block, it computes the hash of the block. If the hash is below the target, the server accepts the block and reads the hash from the beginning of the block. If the hash is above the target, the server rejects it.

So, if the target is 0fffffff.. the client will typically have to perform step 3 (the hash operation) 16 times before it gets a final hash below the target. (There's a 1 in 16 chance a given hash will, in hex, start with a zero.) If that's too easy, set the target to 00fff... and the client will typically have to do 256 block hashes.

You can force the client to do, on average, as many hashes as you want. The actual number of hashes the client will need to do follows a Poisson distribution. The downside is there's always a chance the client will be unlucky and have to do a large amount of work.

If you need to prevent the client from 'reusing' work, you can make the client ask you for  a sequence number. The block then contains the hash, then the sequence number, then the nonce (the part the client increments). You can then validate the sequence number, so the client can't reuse a block it did before and can't pre-compute the blocks.

If you don't like this, you can also pick two random primes and send the product of those primes. Force the client to factor that number. Accept one hash per number factored. Of course, you can make the primes as big or as small as you want to control the amount of work the client needs to do.


How to do Mobile application testing using Burp Suite on latest ios and android devices I am trying to intercept the request with burp suite for mobile application pen testing on iOS and Android devices.

Here are the settings below which I have done in below points.

I made sure that my mobile device and the burp is on same network
All interfaces in proxy options
Downloaded ca certificate on the mobile and enabled from Certificate Trust Settings for PortSwigger CA.
Set the manual proxy on device to same IP address which is on PC.
Asked application team if there is any SSL pinning is implemented and the answer was "NO" from their end.

Information on my issues where I got stuck.

When I intercept the request in burp I see so many error messages the client failed to negotiate an SSL connection.

Finally I came to an understanding that I need to have a rooted or jailbreak device to fully test the application and I am not sure how to do those things in the new version of iOS and android (made in USA)

You sound like you're on the right track. Please try accessing http://example.com/ from the mobile browser - this will confirm that proxying works for non-HTTPS sites.

To install the certificate on recent iOS you must "Enable full trust for root certificates". Instructions here

To install the certificate on recent Android you do need a rooted device.


Provide subjectAltName to openssl directly on the command line Is it possible to provide a subjectAltName-Extension to the openssl req module directly on the command line?
I know it's possible via a openssl.cnf file, but that's not really elegant for batch-creation of CSRs.

Based on link from DarkLighting, here's the command I came up with using nested subshells.

openssl req -new -sha256 \
    -key domain.key \
    -subj "/C=US/ST=CA/O=Acme, Inc./CN=example.com" \
    -reqexts SAN \
    -config <(cat /etc/ssl/openssl.cnf \
        <(printf "\n[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com")) \
    -out domain.csr

All one line:

openssl req -new -sha256 -key domain.key -subj "/C=US/ST=CA/O=Acme, Inc./CN=example.com" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com")) -out domain.csr

Example use:

user@hostname:~$ openssl req -new -sha256 -key domain.key -subj "/C=US/ST=CA/O=Acme, Inc./CN=example.com" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com\n")) -out domain.csr
user@hostname:~$ openssl req -in domain.csr -text -noout
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=US, ST=CA, O=Acme, Inc., CN=example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a8:05:50:86:49:98:c8:05:01:e9:50:18:7f:2f:
                    b4:89:09:29:d1:c1:58:d8:14:bb:58:1d:25:50:11:
                    bb:43:d8:28:03:a5:de:59:49:bb:d2:f7:d3:79:5c:
                    c6:99:2c:98:ff:99:23:8c:df:96:7c:ea:4b:62:2a:
                    a4:c2:84:f5:5d:62:7f:7d:c4:7c:e2:c3:db:e6:58:
                    03:c2:26:9d:02:da:bb:84:d9:11:82:fe:38:12:9b:
                    c7:b6:ff:b2:40:30:38:b1:44:d8:47:1d:43:4a:29:
                    58:6b:49:ec:33:d7:dc:a7:1b:90:05:3a:f5:e6:16:
                    98:08:5d:2d:7e:b4:ea:a2:a4:b1:84:89:f7:f1:c4:
                    67:a6:a1:06:70:dd:4e:6b:0c:f8:b5:9b:bc:3f:06:
                    ee:90:d6:86:29:52:d3:af:f6:d4:2f:c6:cf:4b:5a:
                    b8:cd:01:74:6d:5c:25:a8:02:1c:7c:e8:66:3d:46:
                    07:b1:9d:ef:cc:eb:90:b6:bf:7b:33:e0:5f:b2:9b:
                    e8:b4:12:67:2f:8d:0d:9b:54:9d:95:6e:09:83:cb:
                    f3:5b:1f:31:8e:3b:ca:4e:08:e0:40:c0:60:40:72:
                    dd:0d:3e:99:ec:7c:ac:c4:3c:ba:85:9d:d9:d9:6b:
                    02:2e:bf:a8:a3:02:1d:eb:c8:58:e3:04:b3:a5:f1:
                    67:37
                Exponent: 65537 (0x10001)
        Attributes:
        Requested Extensions:
            X509v3 Subject Alternative Name:
                DNS:example.com, DNS:www.example.com
    Signature Algorithm: sha256WithRSAEncryption
         a2:1d:1a:e8:56:43:e7:e5:c7:c1:04:c1:6a:eb:d5:70:92:78:
         06:c1:96:fa:60:e2:5f:3c:95:ee:75:ed:70:52:c1:f0:a7:54:
         d2:9f:4a:2f:52:0f:d4:27:d8:13:73:1f:21:be:34:3f:0a:9c:
         f1:2a:5c:98:d4:28:b8:9c:78:44:e8:ea:70:f3:11:6b:26:c3:
         d6:29:b3:25:a0:81:ea:a2:55:31:f2:63:c8:60:6d:68:e3:ab:
         24:c9:46:33:92:8f:f2:a7:72:43:c6:aa:bd:8d:e9:6f:64:64:
         9e:fe:30:48:3f:06:2e:58:7c:b5:ef:b1:4d:c3:84:cc:02:a5:
         58:c3:3f:d8:ed:98:c7:54:b9:5e:50:44:5e:be:99:c2:e4:03:
         81:4b:1f:47:9a:b0:4d:74:7b:10:29:2f:84:fd:d1:70:88:2e:
         ea:f3:42:b7:06:94:4a:06:f6:92:10:4c:ce:de:65:89:2d:0a:
         f1:0f:79:90:02:a4:b9:6d:b8:39:db:de:6e:34:61:4f:21:36:
         a0:b5:73:2b:2b:c6:7e:2f:f2:e5:1e:51:9f:85:c8:17:9c:1a:
         b6:59:b0:41:a7:06:c8:5b:f4:88:92:c9:34:71:9d:73:f0:2e:
         31:ae:ed:ab:35:0e:b4:8a:9a:72:7c:6f:7a:3e:5d:66:49:26:
         26:99:e1:69


Why would a certificate authority have multiple root certificates? When I look at the trusted certificates in my browser, I see that many certificate authorities have multiple root certificates associated with them. For example, org-Amazon has Amazon Root CA 1, Amazon Root CA 2, Amazon Root CA 3, and Amazon Root CA 4.
How do the purposes of these four certificates differ?
I also see that some CAs have root certificates of different "tiers", such as gold, silver, and platinum. What's the deal with these? I imagine there are price differences associated with the different tiers, but what extra service could they be offering?

Numerous public CAs have multiple root certificates in trust store for different reasons and largely depends on their business operations. Often roots from same vendor differ by:

List of usages
Public key or signature algorithm support
Assurance level
Redundancy

For example, Amazon Root CA 2 and Amazon Root CA 4 allows Code Signing certificates in their chains, while Amazon Root CA 1 and Amazon Root CA 3 do not allow such. This is "EKU" separation.
Amazon Root CA 1 and Amazon Root CA 3 share same list of usages, but they use different public key and signature algorithms: Amazon Root CA 1 and Amazon Root CA 2 use RSA public key, Amazon Root CA 3 and Amazon Root CA 4 use ECC public key.
This setup provides good level of flexibility, compatibility and security.


Arpspoof on Debian - Linux isn't working I'm using the following code:

>sudo bash
>echo 1 > /proc/sys/net/ipv4/ip_forward
>arpspoof -i wlan0 -t [Victim IP] [Gateway IP] #on terminal num.1
>arpspoof -i wlan0 -t [Gateway IP] [Victim IP] #on terminal num.2

And checking the traffic with WireShark, for some reason no information between the Victim and the Gateway is transferred to me, I'm using netcat chat and I want to intercept the chat between the "Victim" and his "friend" (another computer), the chat is not encrypted.
I also get a "duplicate use of [Victim IP] detected!" error on WireShark from the Gateway that keeps repeating.

Any idea why its not working?

Using 3 RaspberryPi3 with Raspbian Jessie, on wifi.

Try setting your interface in promiscous mode, you can do it as following

ifconfig wlan0 down
ifconfig wlan0 promisc
ifconfig wlan0 up

Maybe it's not necessary to turn down and up the interface


I'm scared if my school can see what I'm searching So I accidently clicked some sketchy website called "doxbin.org" and in that website clicked a dox called "rapey org owner" and I realised I can't deletet search history because of my school administrators so I'm sooo paranoid do they see that I'm also on a school provided device so I am 99 percent sure they can see that if they can how do they see it do they check it themselves or do they get a alert of some kind

Everyone makes mistakes.
You accidentally clicked on a website. That cannot be helped.
How they could, or would do it is up to them, some maybe just ignoring it (I don't know) some others maybe very strictly and carefully looking trough everything. But I don't think you are in any danger, just because of a accidental click on a URL.
It would be totally different if you browsed that website(continued to browse it, still - realizing it might be against the rules of your school, and tried to hide that fact


How does the DANE protocol make Certificate Authorities obsolete? How does the DNS-based Authentication of Named Entities (DANE) protocol make Certificate Authorities (CA) obsolete?

In other words: How is it technically possible that DANE does not need Certificate Authorities?

DANE makes it possible for every owner of a domain to publish its certificate inside the DNS, i.e. fully managed by the owner of the domain which is the owner of the certificate. But, DANE needs DNSSec because otherwise such records could be spoofed which would a major problem with certificates. Thus while DANE does not rely on a certificate hierarchy to build a chain to a trusted root CA it still relies on a similar concept: a key hierarchy with trusted root keys.

The main difference to CA issued certificates is that the domain owner can fully create all certificates belonging to its domain itself and insert it into this hierarchy of trusted keys. Similar revocation is easier since the key has simply to be removed from the DNS. This of course requires that the domain owner is able to manage its own DNS records and that these are protected with DNSSec.


How were hackers able to alter the text of my pages without a form or querystring? I maintain a small site that runs old-fashioned classic ASP pages with an Access backend.

Recently, the site got hacked. The attacker managed to add a large quantity of code to the index.asp page. Mostly it was static content, lots of links to dubious sites, that sort of thing, with a bit of scripting thrown in. I didn't stop to analyse the scripts - I just deleted everything and reposted the page.

There's nothing in that index page which accepts dynamic input: no search boxes, no file uploads, no querystrings. There is elsewhere on the site, which includes some simple forums software, but not on the front page.

Because there's no input on the page that got hacked, I presumed this was a flaw in the host's defences, and alerted them to the fact there might be a problem. After a couple of days, they got back to me claiming they were fully secure and the attacker must have used some form of injection attack to do the damage.

This surprised and alarmed me, because I was not aware that there were techniques to use injection on pages that don't accept any input. But my knowledge of security isn't great, so if there are, I want to know about them.

So, how can an injection attack get on a page that doesn't have a form or a querystring? Or are my hosting company bluffing, and there's a possible flaw in their security?

A vulnerability in active content on your site is not limited to only impacting that portion of your site.  If you have a vulnerability that allows execution of arbitrary code, then the code that is injected can do anything that the executing process can do, potentially including file operations on other parts of your site.

This is most probably what happened.  The forum software or some other form was injected in a way that allowed a file operation to be preformed on the root folder and that was used to modify the static files on the main page to inject the content payload.

It's a mildly sophisticated attack in that it probably wasn't done exclusively with out of the box tools, but still isn't particularly hard assuming the appropriate vulnerabilities were present.


Multiple "Bearer" keywords in single Authorization header I have recently seen a web application that, while using Authorization header, accepted multiple Bearer keywords followed by a valid JWT token. For example, all of the following headers would result in correct authentication:

Authorization: Bearer jwttokenhere...
Authorization: Bearer Bearer jwttokenhere...
Authorization: Bearer Bearer Bearer Bearer Bearer Bearer Bearer jwttokenhere...

and so on. My question is - if the backend accepts such headers, is there any security risk involved here or is it only a matter of how backend handles it? None of other combinations I tried worked (like using "test" as one on the Bearers, placing token inbetween etc.), but I may have missed something. The backend is Java+Spring and it is probably using org.springframework.security.oauth2 to handle JWT tokens.

Just because an application accepts multiple Bearer strings or maybe will work without any Bearer string does not make the application vulnerable. The Bearer string by itself neither adds nor reduces security, the relevant information are all contained in the JWT itself.
Sure, it might be that this behavior is connected to a specific implementation which then results in a vulnerability in another place, but acceptance of multiple or none Bearer by itself does not result in a problem.


Exploiting a service on 32bit OS on a 64bit processor with ShellCode Let's theoretically assume I have an overflow vulnerability on a certain service I want to exploit.
The service reside in 32bit Operating System on a 64bit Processor.
I'm attempting to wrap my head around the coding challenges in regards to the different architecture used on these layers.
Let's also set aside ASLR, DEP, Rebase, etc.
How would the exploit be coded in terms of architecture compatibility if I am to use a shellcode?

The specifics may depend on exactly which architecture pair you are referring to (e.g. amd64 vs x86 or ARM64 vs ARM) and which OS you are referring to. But generally, while the underlying hardware may be capable of executing the instructions from either architecture variation, you can't always freely run the same code across the two due to kernel and userspace constraints. I also don't think you can inject shellcode of a different architecture variant into a running process; not sure if the CPU would know how to handle that.
Regardless of the OS or processor, you should write the shellcode for whatever architecture the target binary itself is compiled for. All of the memory and code that your shellcode will have access to will be limited to whatever architecture the program is. I don't think the architecture of the OS or CPU are too relevant to the running process, as long as it is compatible. Imagine if you had an ARM32 binary running in an ARM64 emulator in an x86 VM running on amd64 hardware. The fact that the bare metal is amd64 has no concern to the binary.


Does A6 - Security Misconfiguration be reported for embedded JS? We have a HTML file with a minified JSlibrary pasted inside with the license header and version number.

Our client reported that it's a security risk (https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration) because the version number of the library is exposed.

If we use an external JS file and just link to the file from the HTML using  tag, will the issue still be reported?

If we use an external JS file and just link to the file from the HTML using tag, will the issue still be reported?

It depends (it always does). When you would do it the way as described below, it most likely will:

<script src="https://external.party.com/mylibrary.js"></script>

The reason is you have no control over the library that is loaded in your website. If the remote host somehow get compromised, malicious code could be injected in the user's browser.

There are two options to prevent this issue:

Serve the library locally

Download the library from the external website and load it from your own web server. Make sure that the downloaded library is considered secure (use the latest stable version)

Subresource Integrity

Subresource Integrity (SRI) ensure that resources hosted on third-party servers have not been tampered with. This is done by generating a hash value of the remote library.

The image above is how you should use the generated hash from the HTML code. If this is the route you want to take, please have a look at Mozilla's web site for further information on how to generate the hash and how to configure the content security policy.

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity


Client-side encryption using public-key My situation:

Login password from a POST request is left in browser memory in clear text as long as cache is not cleared (manually/closing browser).
Connection is HTTPS.

Possible Solution:

Generate public-key and private-key on server for each login request.
Send public-key to browser.
Use JavaScript to encrypt the password with the public-key and send to server.
Decrypt using the private-key and validate.
Delete keys after login.

My question is, is this feasible?  Pros and Cons?  Are there any security vs. performance considerations?

I've gone over a few questions like:

Hashing client side
Webcrypto
javascript crypto

The first one doesn't really answer my question as I'm suggesting generating a new pair of keys on every request (which honestly is my biggest worry as far as feasibility and performance). The other two links seem to suggest that javascript crypto is basically pointless as long as you have an HTTPS connection.  Thoughts?

Generating another public-private key would be overkill for this senario.

If you're really worried about some malware reading the browser cache, you can instruct the browser to just not cache anything.

<meta http-equiv=”Cache-Control” content=”no-cache” />
<meta http-equiv=”Cache-Control” content=”no-store” />

If you're worried about someone reading through the memory to find the plaintext of the username and/or password then you can implement at a solution similar to the one defined in senario #2 here (http://resources.infosecinstitute.com/browser-based-vulnerabilities-in-web-applications/)

Note that you have to scroll down a bit on that page to see the content, there's a giant ad that pops up first.


Rationale behind SELinux preventing file access Some of the few times I've had to deal with SELinux were when I setup a local webserver on a Fedora box. Problems occurred when a web application tried to write files to the file system.

I'm used to setting up Posix file permissions properly, so one of the first steps I always perform is chown apache:apache -R /var/www/. Subsequently, I only use the apache user to interact with the webroot or the web applications.

However, on Fedora, SELinux prevents writing to files. I followed the SELinux troubleshooter's advice to disable this protection, but it got me wondering.

Why would SELinux prevent file write access for a process (apache) when that process is already running as its own user, and regular old file permissions can thus be setup easily, specific for Apache? And are there any other use cases that make (more) sense for this kind of file access prevention?

TL;DR

Set access levels for individual web applications.

Did read

After reading this page, I think I've got a good idea of the rationale. In SELinux, each file has a security context. You can view the current security context with ls -Z <path>, and set a new security context with chcon.

All web apps will be run as the apache user, so under normal circumstances, each web app will have the same permissions. With security contexts, you can confine the access of individual apps/script. By default, scripts have read-only access.

This is actually quite useful for security. Let's say you have an application you trust, which requires write access. You would explicitly give that script the httpd_unconfined_script_exec_t context. Now let's say you have an insecure application that is prone to exploits. You would leave the security context of the script(s) belonging to that application at the default, which prevents writing files.

Preventing file writes would prevent a whole range of attacks which exploit some vulnerability to write a script to disk, which can subsequently be executed over http by the attacker.


How to hide my website traffic from man in the middle? I know that even with HTTPS it's possible to a company proxy to see traffic from/to my website (e.g. Intercepting HTTPS Traffic Using the Squid Proxy Service in pfSense).

I want my users to have total privacy. Is there a way to secure the data, maybe using Javascript, or a second layer of SSL, etc.? Is there an open solution elsewhere?

Client browsing your web site will receive a certificate warning if the connection is going through a proxy unless the MITM server uses a CA that the client trusts as well for the connection so there is no real vulnerability as long as your users maintain their own security.

Alternatively, you can require TLS client certificate authentication on the server. You will then have to manage the secure distribution of the client certificate you accept but as long as this part of the setup holds, it won't be possible to perform a MITM attack on the connection.