Cancelling a request stops new authentication cookie getting to browser, invalidating all further requests I am trying to secure my login system using authentication cookies.

If the user tries to access a protected resource they must provide an authentication cookie. If the cookie is valid, the request is authenticated and the resource is returned, along with a new auth cookie for the user.

I rotate the auth cookie as an extra protective measure. In case anyone managed to steal it, it would only be valid until you made your next request.

However, if the user makes a request and the server authenticates it, but before the resource and new cookie reaches the client the user closes the browser, then that means the browser's cookie is not the same as the token in the database. Any further requests can't be authenticated and the user is forced to log in again.

What's the correct approach to this? Should I not send a new token with every response? Should the browser confirm that it received the new token?

The normal way to do this is to have one constant session ID in a cookie. It's a long random number that gets set when the user logs in, and is stored and verified on the server. That's how sessions are handled in most frameworks and languages.

Unless you are doing something special, there is no need to change the session ID on every request. Doing so causes you a lot of problems, like the one you describe. Also, what happends if the user has your page open in multiple tabs at the same time? And so on, and so on.

So unless you have some very specific need to change the token, why would you? It is not a very effective protection against session hijacking (i.e. the cookie being stolen), since an attacker can do a lot while the victim is viewing the page. It is not worth the trouble and the extra complexity it brings.


Invalid passwords leaked to logfiles My company recently discovered that we're logging invalid login attempts, alongside with usernames and passwords. Those logfiles are stored on several machines and accessible to all team members.
This was of course not our intention (introduced by previous team) and we already patched it.

What are the threats posed by this situation? Should we notify users about that or just remove entries from logs and move on (those were invalid passwords after all)?

Bonus question: How can I convince decision-makers to make the right choice?

The threats is that if anybody of the team members is crooked he/she could guess the correct password. Invalid login attempts - it seems to me - are because of 3 reasons:

spelling mistakes for password or user name
wrong password or username
invalid attempts (hitting enter too early, no password at all etc)

Now for the spelling mistake it is very possible that it is easy to guess the password. If the wrong password is used then it may be the password for a different service. So the obvious threat is that anybody that has had access to the logfiles may abuse this information and impersonate somebody.

You can convince decision makers by asking them how they would react if their accounts would be compromised. It would be a bonus for you if you can find an actual account of one of the decision makers and a bad password attempt.

But in the end they are responsible for making the right choice. If they decide just to delete the files then you may protest, but in the end you'll have to decide if your moral obligation to the users weighs more than your job.

Personally I would inform the users, but I don't own a company.


Is exposing the server time a security risk? If I create a servlet that would return the server time publicly (no need for authentication), would this be a security issue? I couldn't think of any issue with this, but somehow something tells me I could be wrong.

To explain more, this end-point will be used by mobile apps to enhance their security (to avoid cheating by adjusting the device date).

The server time is of little use to an attacker, generally, as long as it is accurate. In fact, what is being revealed is not the current time (after all, barring relativistic physics, time is consistent everywhere) so much as the time skew. Note that, even if you do not explicitly reveal the time, there are often numerous ways to get the local server time anyway. For example, TLS up to and including version 1.2 embeds the current time in the handshake, web pages may show the last modified dates of dynamic pages, HTTP responses themselves may include the current time and date in response headers, etc.
Knowing the exact clock skew of a server is only a problem in very specific threat models:

Clock skew can be used in attacks to deanonymize Tor hidden services.

Poorly-written applications may use server time to generate secret values.

Environmental conditions of the RTC may be revealed in contrived situations.


Block cipher algorithms with block size of 64 bits (like DES and 3DES) birthday attack known as Sweet32 I am using nodejs and Ubuntu.

When i scan my domain on trustwave.com i got following error

Block cipher algorithms with block size of 64 bits (like DES and 3DES) birthday attack known as Sweet32

  This is a cipher vulnerability, not limited to any specific SSL/TLS
  software implementation. DES and Tripple DES (3DES) block ciphers with
  a block size of 64 bits, have a birthday bound of approximately 4
  billion blocks (or 2 to the power of 32, hence the name of this
  vulnerability). A man-in-the-middle (MitM) attacker, who is able to
  capture a large amount of encrypted network traffic, can recover
  sensitive plain text data.

and This issue can by avoided by disabling block ciphers of 64 bit length (like DES/3DES) in all the SSL/TLS servers. Exact procedure depends on the actual implementation. Please refer to the documentation of your SSL/TLS server software and actual service software (http server, mail server, etc).

NOTE

  1: This finding is based on a live test that actually detects which
  ciphers are supported by the server. It is very important to note that
  in many cases, a software update (backported version provided by
  Operating System vendor or "vanilla" release taken directly from
  SSL/TLS vendor) won't be enough to resolve this issue. Usually
  software update doesn't overwrite manually tweaked configuration
  files, which means, DES/3DES can be still available, even if the
  software update disables them by default.

I am new to nodejs and sever thing,

I used following code

var constants = require('constants')
  , https = require('https')
  , path = require('path')
  , tls = require('tls')
  , fs = require('fs');
var sslOptions = {
  key: fs.readFileSync('/etc/ssl/private/private.key'),
  secureProtocol: 'SSLv23_server_method',
 secureOptions: constants.SSL_OP_NO_SSLv3 | constants.SSL_OP_NO_SSLv2 | constants.SSL_OP_NO_TLSv1,
 // secureOptions: require('constants').SSL_OP_NO_TLSv1,
  cert: fs.readFileSync('/etc/ssl/certs/STAR_w.crt'),
  ca: [
            fs.readFileSync('/etc/ssl/certs/AddTrustExternalCARoot_1.crt'),
            fs.readFileSync('/etc/ssl/certs/AddTrustExternalCARoot_2.crt'),
            fs.readFileSync('/etc/ssl/certs/AddTrustExternalCARoot_3.crt')
        ],
  ciphers:[
    "ECDHE-RSA-AES256-SHA384",
    "DHE-RSA-AES256-SHA384",
    "ECDHE-RSA-AES256-SHA256",
    "DHE-RSA-AES256-SHA256",
    "ECDHE-RSA-AES128-SHA256",
    "DHE-RSA-AES128-SHA256",
    "ECDHE-RSA-DES-CBC3-SHA",
    "DES-CBC3-SHA",
    "ECDHE-RSA-DES-CBC3-SHA",
    "DES-CBC3-SHA",
    "HIGH",
    "!aNULL",
    "!eNULL",
    "!EXPORT",
    "!DES",
    "!RC4",
    "!MD5",
    "!PSK",
    "!SRP",
    "!CAMELLIA"
].join(':'),
  //ca: fs.readFileSync('/etc/ssl/certs/AddTrustExternalCARoot.crt'),
  requestCert: false,
  rejectUnauthorized: false
};

Any idea how to disable chiper?

Thanks

The answer to your question is included in your question. To cite:

  This issue can by avoided by disabling block ciphers of 64 bit length (like DES/3DES) in all the SSL/TLS servers.

Thus remove the following ciphers which you have explicitly added to your configuration:

"DES-CBC3-SHA",
"ECDHE-RSA-DES-CBC3-SHA",

Note that you should remove all use of these ciphers because for some unknown reason you have added these ciphers twice. Additionally you should explicitly deny any 3DES ciphers which might or might be not included in your HIGH setting (depending on the version of OpenSSL) by adding an explicit !3DES to the cipher set.

Apart from that I recommend to follow known good ciphers sets like the ones recommended by Mozilla.


What is the core purpose of a firewall on a linux server that is connected to the internet? When I deploy new linux servers - I start off with a bare bones Ubuntu Server OS and install only the services that are needed.

SSH
webserver - port 80

These services have iptables rules setup to ACCEPT connections to them
 - so the firewall provides no benefit in that regard.

The server gets frequent requests to all sorts of ports - ranging
from 22 to 56,000 - but no services are listening or responding to those ports.

If the server had no firewall the server's network stack will respond with a RST reset packet - otherwise the server would provide no services to the attacker on that port.

With a correctly configured firewall , iptables will silently drop these packets to the floor.

if the attacker scanned all ports they would eventually find the open ports and therefore establish that the server is connected to the internet and get a mapping of the ports accepting connections.

So is the core benefit of a firewall on a server, to basically slow down the speed at which an attacker gets a mapping of open ports?
If not, what actual purpose does a firewall have on a server?

In my setups the purpose is to prevent accidentially opening ports to the public which could allow random attackers to do bad things. For example, you could test configuration of an email service which comes as an open relay out of the box. If there is no firewall and you forget to turn it off you are spamming probably after a few hours already.

Any kind of software can open a port, sometimes you dont know. So thats why I like to have a global firewall where I explicitly can allow certain minimum ports to be accessible.

Start with only having SSH enabled (and direct root logins disabled of course), and then only open new ports if the service to be exposed is fully configured and hardened.

In the end, as you say, there might be only 4 or 5 ports opened in the firewall, all the other connections will be refused.

Note also that a firewall can be configured to deliver RST packets instead of silent drops (with REJECT policy). This is more compliant to RFCs of course, and still does not expose any risks. If you want to slow the scanner, then of course, use DROP policy.


Using remote desktop I was having trouble getting Outlook to work with my schools email account and called the help desk. They gave me a link to install a program called Bomgar. I installed it and clicked "allow viewing and control" and some random guy had complete control over my computer. My question is how safe is this stuff and how can you prevent the controller from messing with stuff you don't want touched? Short of unplugging my computer I wouldn't know how to stop his control.

Can you see everything he does when connected or can he be doing things to the computer even though the mouse and nothing else appears to be moving?

EDIT: it still wasn't working so I called the help desk again and their solution is to disable the antivirus e-mail shield.

If you setup a similar environment within a VM its very unlikely that the remote controller could break out of the VM into your main machine.

If you are running as an unprivileged user, the remote user may only have those privileges. I suggest at the very least only running the program as a limited user with the ability to change outlook settings. Otherwise, he has complete control of your machine. Depending on how the software is written, the controller may or may not be able to hide actions from you. This is horrible security wise for you and I would rather take it to help desk in person and watch them work, or only let the person do his work in a VM, then mirror the settings on your own on your machine.

You are giving this person complete control over your computer.

Honestly doing all of your work within a VM has its benefits, such as being easier to backup, and being able to recover from just about anything through snapshotting.


Sample challenge questions for use with self service password reset and validation I'm building a secure password recovery feature similar to the one described here.

During the final phase of the password recovery, the user is asked a recovery question to verify their identity.

Does anyone know where I could find a list of sample recovery questions?  Ideally these questions would either be vetted for culture sensitivity, or if it's possible, also be humorous in nature (relating to the theme of the website)

Try the following: goodsecurityquestions.com - it provides a list of good and bad examples, along with guidelines on how to think about security questions. They also state that their guidelines have been used by Prudential, Delta Airlines, American Express and ING Direct.

Interesting quote from the site:

  However, there really are NO GOOD security questions; only fair or bad
  questions. "Good" gives the impression that these questions are
  acceptable and protect the user. The reality is, security questions
  present an opportunity for breach and even the best security questions
  are not good enough to screen out all attacks. There is a trade-off;
  self-service vs. security risks.


Cracking MS-CACHE v2 hashes using GPU As most people here will know, Windows caches domain/AD credentials in a format known as MS-Cache v2. Obviously, these would be excellent passwords to gain during a penetration test when local access is obtained on a workstation.

My understanding is that these can't be attacked using rainbow tables. However, aside from using JTR and Cain, I don't see many options in software to crack them.
Specifically, I'd like to use my GPU's (4x Nvidia cards) to try and crack these.
Alternatively, if I could run distributed software, that would be a reasonable second best.

A few questions then:

What options are there for recovering MS-Cache passwords?
Can anyone provide a technical breakdown of how MS-Cache (v2) is generated/attacked?
Is MS-Cache v2 used to encrypt credentials stored on a domain controller?

Edit:

I'm only interested in MS-Cache v2 Hashes as generally i wouldn't come across machines older than Windows XP in a domain.

MS-Cache is a pretty simple format - it's an MD4 hash of the password, followed by the username in lower case, and hashed together MD4( MD4(Unicode(password)) + Unicode(tolower(username)) ). I'm not sure of the technical difference between MS-Cache and v2; but nothing I can find suggests they're not susceptible to a RainbowTable attack (in fact, Cain & Abel seems to have support for MS-Cache and MS-Cache v2 tables - "Added MSCACHE v2 Hashes Cryptanalysis via Sorted Rainbow Tables" in v4.9.4).

The MS-Cache credentials are not stored on the domain controller (except for users that logon to it directly) - they are stored as MD4 hashes of the passwords, related to the username. You may be interested in this technet piece about how they're hadled.

Regarding GPU accelleration, it looks like John the Ripper has MD4 support; that may be what you're after. Otherwise there is this article on attacking Windows passwords with the GPU (specifically, you may be able to adapt ighashgpu for your purposes) and, as mentioned by Lucas in the comments below; rcracki_mt has GPU support.

[Update]

MS-Cache v2 is described in detail (with code) at openwall.info, and importantly PassLib mentions it's also known as 'DCC2', which may help with future searches (though info is frustratingly scant). As for attacks against it, from openwall:

  In other words, incremental brute-force attacking for different search spaces, depending on the character set and the password length, will take ages. So it is a good idea to do some intelligent password guessing when attacking DCC2 hashes, i.e. rule-based dictionary and probabilistic attacks.

With that python module and PassLib you should be able to put together something involving PyCUDA and PassLib, but it doesn't look like it's been done by anyone before.


JWT encoding using HMAC with asymmetric key as secret I'm currently exploiting the vulnerability discussed here

https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/

Where the algorithm type in JWT can be changed from RSA to HMAC and signing the token with a given public key.

However, I wrote the below python code:

import jwt
import base64

# consider 'publickey' as the servers public key
code =
jwt.encode({'login':'test'},'publickey',algorithm='HS256')

This Throws an error :

InvalidKeyError: The specified key is an asymmetric key or x509 certificate and should not be used as an HMAC secret.

Im looking for an alternative where I can successfully sign it using the asymmetric key.

Thanks

Use an old version of pyjwt (0.4.3) where this exception wasn't implemented yet.

pip install pyjwt==0.4.3


Is GPON uniquely vulnerable to eavesdropping exploits from neighbors on same network? If so, why? Background
A fellow in my social circle is involved with a cybersecurity company that secured a patent. I want to learn more.
Simple Explanation
US Patent Office Listing
Patent analysis is a very tedious and expensive process. I don't expect anyone on a free tech support site like this one to read the complete patent (it's long!) or provide analysis regarding its viability or monetary valuation. I'm simply trying, as a non-expert in security issues, to get a basic handle on:
Q. What problem is being solved?
It appears that the company patented a security mechanism to foil a specific eavesdropping exploit wherein peers on the same GPON (Gigabit Passive Optical Network) can see each others' traffic. This seems like a major security hole for such a mature technology like GPON -- so major, in fact, that I feel I'm missing something.
Q. Why is this solution necessary?
When cable modems came on the scene, I recall there was a brief period where neighbors could see each others' IP traffic. The issue was resolved in time, presumably using encryption of some kind. Why can't a similar solution be used with GPON?
My own Research
As an outsider to both fiber optics and cybersecurity, there's only so much I can absorb and understand. However, I did review the wiki article that discusses GPON. This sentence caught my attention:

In most cases, downstream signals are broadcast to all premises
sharing multiple fibers. Encryption can prevent eavesdropping.

I take this to mean that if a building is wired for GPON, the tenants will be able to see each other's traffic since "downstream signals are broadcast to all premises sharing multiple fibers." But then the next sentence states that encryption can prevent eavesdropping. Which leads a man to wonder: If encryption can be used to prevent eavesdropping, what exactly is the security issue that's being addressed here?
Related
Here's an earlier, reworded version of my question on dslreports. The brief discussion with a dude there is helpful but figured I'd get the opinion of the security professionals in this group as well.

DISCLAIMER:  I am not a patent attorney, and I am not well versed in GPON networks.  The following is my layman's take on US Patent 10,904,649.
I took a look at the patent that you referenced (US Patent 10,904,649).
After reading the text and looking at the drawings, I agree with your conclusion that the invention disclosed in the '649 patent generally aims to solve the problem where peers on the same GPON can see each others' traffic.  However, I don't believe the method claimed in the '649 patent uses encryption to solve the problem.
As you point out, methods to solve this problem have existed for a many years (long before the application was filed in 2019).  The fundamental requirements for patentability are uniqueness and non-obviousness.  So, what's unique and non-obvious here?
To answer these questions, I took a look at the claims of the '649 patent, to see exactly what is claimed in the specification.  As you may know, the claims of a patent specify exactly what systems/methods another entity may not [build | use | sell | export] - without obtaining a license to do so from the assignee of the patent (otherwise this entity would be infringing the patent).
There are only four claims in the '649 patent, and only one of these claims (claim 1) is an independent claim (the other four claims are dependent claims of claim 1, which means they are 'special cases' of claim 1).  Claim 1 reads:
1. A digital data network communication method comprises:
  accepting a plurality of private data streams into at least one passive optical network interface router serving a plurality of private user devices through a plurality of optical network units (ONUs);
  configuring said at least one passive optical network interface router to virtually separate information intended for each of said plurality of private user devices, wherein said configuring comprises:
    generating an independently unique virtual routing table for each of said plurality of private user devices using Virtual Routing and Forwarding (VRF);
    uniquely tagging ethernet frames contained in said plurality of private data streams and intended for said first one of said plurality of private user devices according to entries in a first one of said virtual routing tables associated with said first one of said private user devices using Multi Protocol Label Switching (MPLS) to form MPLS tagged data packages;
    sending said MPLS tagged data packages to a passive optical networks optical line terminal (OLT);
    aggregating within said OLT said MPLS tagged data packages into a common data feed; distributing said common data feed to said plurality of ONUs;
    wherein said distributing comprises: replicating said common data feed using at least one optical splitter connected to said plurality of ONUs;
    extracting, at each of said plurality of ONUs, from said common data feed those MPLS tagged data packages intended for a specific one of said plurality of private user devices.

As you can see from the above claim - there is no mention of encryption, or anything relating to encryption, anywhere in the text.  However, after reading the above claim, my feeling is that this a very specific method of solving the problem where peers on the same GPON can see each others' traffic.
Often with patent prosecution, the original patent application filed by the inventor contains very broad claims for systems/methods aimed at solving some problem.  During examination, the examiner often finds 'prior art' that predates the systems and methods described in the claims.  The inventor can then go back, and narrow the scope of their claims, or eliminate some of the claims altogether, to avoid 'reading on' the prior art.  Then, the inventor can submit the revised claims for re-examination.  This tends to result in fewer claims that are much narrower, and much more specific.  This may have been what happened with patent application that eventually matured into the '649 patent.  A look at the patent file wrapper (which shows the back-and-forth between the inventor's attorney and the patent examiner during examination, as well as each revision of the inventor's claims) would show if this is what happened in this case.


Do servers store my previous passwords? When I change my password on some web servers like email, cloud, and social networks and try to use my previous password, the server denies it with message "Don't use your previous passwords".

Does that mean that servers store my previous passwords? How is that secure?

Hash functions are deterministic; the same input always results in the same output. They can store the previous hash values of your old passwords and compare them with your new proposed password's hash. To achieve this, they also need to store at least the salt values, too. This means the salt and other parameters has to be the same for you in this site.

As pointed out by Micheal

  The salt for the old passwords does not have to be the same as the new one.

In this way, you can use different salts and other parameters. This can be considered more secure than reusing the salt with an increase on the storage.

From here, without the server side code, we cannot say more than like this.


What would be the impact of a CVE-2015-9251 vulnerability? I've seen that in jQuery versions older than jQuery 3 there is the CVE-2015-9251 vulnerability which can result in cross-site scripting. Is this a limited vulnerability? What could be its possible effects? Should it be treated dangerous?

https://github.com/jquery/jquery/issues/2432

Is this a limited vulnerability?

It is limited in the sense that the vulnerability can only apply if your application is querying via $.get an untrusty/compromised website.

  What could be its possible effects?

As per the CVE, your application would be vulnerable to XSS and all of its implications.

  Should it be treated dangerous?

As much as any XSS execution in your application would be.


How does one scan a MySQL database for malware? I have a lot of means of searching for malicious code within the file system, monitoring traffic, scanning log files, checking for suspicious/masked processes etc.

However, scanning a relational database such as MySQL is no easy task. Some exploits such as the Magento Shoplift from 2015 aim to inject malicious code within the database being aware of its structure and how it cooperates with the server-side application(s). Dumping the database and then running a signature-based search would be utterly inefficient as some of data is stored in BLOB and other types of data. Also, it is not necessarily looking suspicious and is far from what a PHP webshell might look like, for instance.

My question is: what is the most practical and efficient way to detect anomalies and spot malicious code in a MySQL database?

Could the following be considered a decent approach?

Dump the database;
Check it line by line compared to the same database from a backup archive;

say using a functionality similar to that of diffchecker.com;

Analyze the newly inserted/updated data;

this might involve skipping large amounts of data which is clearly not that of any malicious behavior;

Thank you.

Interesting question. First you have to define what kind of malware you are looking for. In this case this might be:

Malicious data: Modified data that lost integrity.
Malicious code: Established, embedded or modified data that is capable of running (e.g. executable binaries, stored XSS).

If you are trying to detect malicious data you might chose one of the options:

Analyse the data for integrity by using regex. This might take a lot of time for preparation because you have to know how exactly your data structures have to look like.
Compare legitimate data to the current data sets to detect differences. You might create a hash value of fields, records or tables and compare them once in a while. Storing them in the same database might not be advised. Use another database or even another medium for that (e.g. a file-based approach). If an attacker is able to compromise the database and influence integrity, he might not be able to do the same on the file-system.

This approach might be able to detect malicious code also. But you might be able to use other techniques to detect it properly:

Use a signature-based approach to determine malicious code fragments. The easiest way is to screen you fields. But this expects the data to be in a format which is understood by the scanning engine. If you are serializing or encoding your data, this might hurt the detection possibilities.
You might want to create a dedicated API access possibility for you scanning desires. Your database must provide the data like it would be within an attack. For example if you are using your data within a mail attachment, your API shall create such an attachment to make it possible to be scanning how it will be in the end. Other examples are file-based and web-based output.

Signature-based scanning approaches are error-prone, inefficient and slow. If you have the chance to establish an integrity checking as soon as data is written, this might be much more solid.


How to prevent XSS when transferring web page content within XML I have an ASP.NET web application which uses HTTPS and XML based request-response. It seems a user's session cookie can be retrieved via XSS, if the request/response is intercepted and malicious JavaScript code is added as a payload.

Since it is an XML based request-response, the payload has to be HTML encoded. Here is an example:

&quot;&lt;iframe name=&quot;if(0){\u0061lert(1)}else{\u0061lert(document.cookie)}&quot; onload=&quot;eval(name)&quot;/&gt;

Is there any way I can stop executing any malicious script?

How to identify a request/response containing a malicious script? I noticed that all malicious scripts must contain &quot;, &amp;, ( and ), but user data may also contain these characters.
How do I stop such a script to be run on users' browsers? I have already tried decoding all request/ response to corrupt the script which works, but my requests/responses contain user data which contains characters like &amp;. This leads to the whole XML to become corrupt, which crashes the application.

You are on the right track, with XML encoding. You can't predict all possible malicious content, so encoding dynamic data to guarantee it is benign is the right approach. The issue you've run into is that things get really wonky if you try to handle output encoding for multiple output locations all at once. The right approach (and you're close) is to encode for the current output location only, and let other output locations encode for themselves.

I think the thing that is confusing you is that you are thinking of the XML as though it is the raw output to the HTML. You need to consider the XML as part of your network communications protocol stack, and the HTML as separate output.

If I read this correctly, you have some server code that writes an XML message, and some client code that runs in the web browser, receives the XML message and writes to HTML, JavaScript, URL or CSS context.  (If I read incorrectly, then you probably have a back end writing XML to a front end that is writing HTML, JavaScript, URLs and CSS. In this case, just consider the front end to be the client of the back end in the rest of this post.)

Therefore, the server is responsible for safely writing XML and the client is responsible for correctly writing HTML, JavaScript, URL and CSS data.  This way, the code writing the output is responsible for the safe presentation of that output.


Why is there a path to a .pdb file in an exe I am trying to reverse? My query is ,if I'm  seeing a .pdb path in a exe(VC++) what conclusion  can I draw from it.Why does the exe have these paths and  does it have significance in malware analysis?
eg H:\ConsoleApplication1\Release\ConsoleApplication1.pdb but when the exe will be given to a customer this file will not be present on their H drive,so is this the case of a debug version exe rather than a release version exe?

The .pdb contains information for the compiler. It contains debugging symbols. It also contains names of library's that are used in the application and also names of forms and resources. The reason why you are seeing .pdb path in the exe file is because it was released with debugging turned on. If you got hold of .pdb file it could help you reverse engineer the program.


SSL Certificate - is passphrase necessary and how does apache know it? I want to generate a Certificate Signing Request for my server and in order to do so, I first need a secure private key. When I create a private key by using openssl genrsa -des3 -out server.key 2048, I'm asked to provide a passphrase. After doing some research, I found out that not having passphrase is a high security risk because once my private key gets compromised, the hacker will be able to decrypt everything that was encrypted using my key.

My question is: how is my server supposed to work with a private key that needs a passphrase. Since it is headless, there is no way I can enter the key when my server boots. How is Apache going to handle that?

I'm not asking how to remove the passphrase (I know how), I'm rather interested in how will my server be able to handle it and is it really a big security risk not to use a passphrase? I mean once the web server gets compromised, wouldn't it be easier to install a trojan horse?

If you protect your private key with a passphrase, then Apache is unable to use it unless you supply Apache with the passphrase each time it restarts or you reboot.  And since keeping that passphrase stored in the filesystem would defeat the point of the passphrase, that means having some sort of method to pass the passphrase to Apache from externally, each time it restarts or you reboot.

Some people do this, but its impracticality means most people use a non-encrypted private key.

If your private key is not encrypted, then its protection comes from the fact that only your superuser can read it, and therefore relies heavily on the integrity of the system and how susceptible it is to privilege escalation or the like.

If your private key is compromised then you can go to the signing certificate authority and ask them to revoke the certificate.  Revocation is not a magic bullet however with some systems not checking for revocation and a typical delay between revoking a certificate and the information about the revocation being checked.

  once my private key gets compromised, they hacker will be able to decrypt everything that was encrypted using my key.

This scenario is the kind of thing forward secrecy is designed to prevent. In TLS the two communicating parties can, if they both have the necessary support, negotiate settings which enable forward secrecy, so that in the event the private key is compromised it's still impossible to decrypt past communications.

The SSL Server Test can check to see if Forward Secrecy, among other things, is working on your server.


Does end to end encryption have applications/use cases outside of messaging/email? I was reading up on end to end encryption and I mostly found applications in messaging (Whatsapp, Telegram etc) and well, email (PGP (sort of?)).

I am curious to know if there are applications for End to end encryption beyond these. Say, communication between two processes in a distributed system? Not sure if they really need end to end encryption.

I think just asking for use cases of end-to-end encryption is a very broad question. But in general: whenever two parties exchange sensitive information which need to be protected against sniffing (and probably also modification) by a third party end-to-end encryption makes sense. This includes for example direct messaging, mail communication, protecting passwords entered into web sites, protecting your online banking, telephony, accessing a remote desktop, management of a remote device in the context of IoT and many many more.

You should also note what end-to-end encryption does not offer. While (almost?) all end-to-end encryption implementations protect the message against modification they often don't provide the assurance that the sender is the claimed one or that no message are lost or that messages got replayed. But these are often requirements you have in end-to-end scenarios and which then need to be provided by additional techniques, like cryptographic signatures or message counters.

And then there are cases where end-to-end encryption does not provide the protection one might hope. For example, if you have two processes on the same machine and owned by the same user then end-to-end encryption probably does not make much sense. It does not protect against a user with same or higher privileges since this user could ptrace the applications to extract the unencrypted data from there. For this scenario a communication using (properly protected) UNIX domain sockets or use of socketpair or pipe offers the same protection but without the overhead of encryption.


Is it safe to keep some data and a copy of it encrypted with same key but different salt and IV? I have an application that keeps it's data in classes (not database). for saving data I use binaryformatter and convert this data to memorystream then encrypt it. for being safe, I want to keep a backup of this data. so I would have same data encrypted with same key but different salt and counter(IV) . Is this safe or having same data with same key will endanger security?

I tried to add a class with random length fake bytes to data and set it in start, so files will have different sizes and their data will not be exactly same, but it seems binaryformatter have it's own order and I can not ensure that this class will be in start of encrypted file (is there a way to do this?)

You can safely encrypt same plain text twice with the same key and different IV. Please see this and this.

You need to be careful not to reuse same key/IV combination on two different plaintexts. You will always need to generate new IV for every plaintext you want to encrypt.

Also, for most modes IV needs to be random and not counter. When you choose mode of operation be sure to check IV requirements and follow them.


OWASP ZAP: How to use TLS client certificate authentication? Is there a way to get OWASP ZAP to send a client certificate?

I have an HTTPS website that receives client certificates for authentication. I have the certificates installed in the browser. Previously, when I went to the website (in Firefox), I would be prompted to select one of the installed certificates. I would then be authenticated with the website as the user associated with the certificate.

However after setting up the browser to use a proxy, I am no longer prompted to select a certificate and then the browser just displays this message:

"400 Bad Request
No required SSL certificate was sent
nginx/1.10.2"

It looks like I need to get OWASP ZAP to send the certificate in place of the browser or, somehow, get the browser to force ZAP to forward the certificate. Is there some way for me to do this? Is this something that ZAP supports?

Edit:
My setup works like this: There are three components. Firefox, OWASP ZAP and a Selenium project. Previous, it was just Selenium and Firefox.
The application I am testing has multiple users with different roles. The Selenium test cases involve logging in as one user, performing a task as that user (which generates work for another user), logging in as the next user, performing work as that user etc. Each user has its own certificate to log in.

Previously, I created multiple Firefox profiles (one for each user) and added a single certificate for each profile. When I accessed the site with one of these profiles, the browser would default to the single certificate. Selenium could then switch between users by closing the old browser and opening a new one with the correct profile.

Right now, I use ZAP by opening the appropriate browser profile, setting the proxy to localhost:8080, starting the ZAP GUI, and then running the Selenium test which uses the aforementioned profile. Latter I manually set the contexts, run the spider and switch to Attack Mode. Thus far, I have been helped in getting ZAP to use a single certificate at a time, which has been a significant change.

You should be able to add any certificates that you need to use via the ZAP Options / Certificate screen (https://github.com/zaproxy/zap-core-help/wiki/HelpUiDialogsOptionsCertificate).


Is SiteKey a valid defense against Phishing? As described here, some banks use a SiteKey mechanism in an attempt to provide a defense against phishing. (This is a scheme where the user is shown a personalized image (each user has their own custom image) after the user enters their username but before they enter their password. In theory, this is supposed to let the user verify they are on BOA's page, not on a phishing site.)
The comments and answers indicate some issues with this approach, but that question wasn't about whether or not the approach is effective.

For future visitors who might be considering using the same scheme, I'd like to have the question on the site:

Is this a valid defense against Phishing?  Perhaps not by itself, but as one step in a defense-in-depth strategy, or does this give a false sense of security?  If so, is it just useless, or is it more dangerous to employ this scheme because of the false sense of security?

SiteKey is not an effective defense against phishing.  In principle, it could be helpful for a tiny population of expert users who are very conscientious about examining the image and know how web security works, but those users are rare.  However, a mechanism like this really needs to help protect average users, not just computer security experts.  And, for typical users, SiteKey is not an effective defense against phishing, for reasons explained below.

The good news is that, today, phishing appears to be relatively low on the scale of risks.  Phishing attacks don't seem to be very successful today.  Therefore, the deficiencies in SiteKey may be acceptable.  That said, SiteKey is mostly security theater: it doesn't add much security, for the typical user.

I should elaborate on how I can make such strong statements.  As it happens, this question has been studied in the research literature and there is experimental data on it -- and the data is fascinating.  The data turns out to have some surprises for all of us!

Experimental methodology.
SiteKey's use of a custom "security images" (and security phrase) has been evaluated in a user study, conducted with ordinary users who were asked to perform online banking in the lab.  Unbeknownst to them, some of them were 'attacked' in a controlled way, to see whether they would behave securely or not and whether the security images helped or not.

The researchers evaluated two attacks:

MITM attack: The researchers simulated a man-in-the-middle attack that strips off SSL.  The only visible indication of the attack is that lack of a HTTPS indicator (no HTTPS in the address bar, no lock icon, etc.).
Security image attack: The researchers simulated a phishing attack.  In this attack, it looks like the users are interacting with the real bank site, except that the SiteKey security image (and security phrase) is missing.  In its place, the attack places the following text:

  SiteKey Maintanance Notice:
  Bank of America is currently upgrading our award winning SiteKey feature. Please contact customer service if your SiteKey does not reappear within the next 24 hours.

I find this a brilliant attack.  Rather than trying to figure out what security image (or security phprase) to show to the user, don't show any security image at all, and just try to persuade the user that it's OK that there is no security image.  Don't try to defeat the security system where it is strongest; just bypass the entire thing by undermining its foundation.

Anyway, the researchers then proceeded to observe how users behaved when they were attacked in these ways (without their knowledge).

Experimental results.
The results?  The attacks were incredibly successful.

Not a single user avoided the MITM attack; every single one who was exposed to the MITM attack fell for it.  (No one noticed that they were under attack.)
97% of those exposed to the security image attack fell for it.  Only 3% (2 out of 60 participants) behaved securely and refused to log in when hit with this attack.

Conclusions.
Let me attempt to draw some lessons from this experiment.

First, SiteKey (and security images) is ineffective.  SiteKey is readily defeated by very simple attack techniques.
Second, when assessing what security mechanisms will be effective, our intuitions are not reliable.  Even expert security professionals can draw the wrong conclusions.  For instance, I've seen some competent and knowledgeable security folks argue that security images add some security because they force the attacker to work harder and implement a MITM attack.  From this experiment, we can see that this argument does not hold water.  Indeed, a very simple attack (clone the website and replace the security image with a notice saying the security image feature is currently down for maintenance) is extremely successful in practice.

So, when the security of a system depends upon how users will behave, it is important to conduct rigorous experiments to evaluate how ordinary users will actually behave in real life.  Our intuitions and "from-first-principles" analyses are not a substitute for data.
Third, ordinary users don't behave in the way security folks sometimes wish they would.  Sometimes we talk about a protocol as "the user will do such-and-such, then the server will do thus-and-such, and if the user detects any deviation, the user will know he is under attack".  But that's not how users think.  Users don't have the suspicious mindset that security folks have, and security is not at the forefront of their mind.  If something isn't quite right, a security expert might suspect she is under attack -- but that's usually not the first reaction of an ordinary user.  Ordinary users are so used to the fact that web sites are flaky that their first reaction, upon seeing something odd or unusual, is often to shrug it off and assume that the Internet (or the web site) isn't quite working right at the moment.  So, if your security mechanism relies upon users to become suspicious if certain cues are absent, it's probably on shaky grounds.
Fourth, it's not realistic to expect users to notice the absence of a security indicator, like a SSL lock icon.  I'm sure we've all played "Simon Says" as a kid.  The fun of the game is entirely that -- even when you know to look out for it -- it is easy to overlook the absence of the "Simon Says" cue.  Now think about a SSL icon.  Looking for the SSL icon is not the user's primary task, when performing online banking; instead, users typically just want to pay their bills and get the chore done so they can move on to something more useful.  How much easier it is to fail to notice its absence, in those circumstances!

By the way, you might wonder how Bank of America (or other banks who use similar methods) have responded to these findings.  After all, Bank of America emphasizes their SiteKey feature to users; so how have they reacted to the discovery that the security image feature is all but useless in practice?  Answer: they haven't.  They still use SiteKey.  And if you ask them about their response, a typical response has been something of the form "well, our users really like and appreciate SiteKey".  This tells you something: it tells you that SiteKey is largely a form of security theater.  Apparently, SiteKey exists to make users feel good about the process, more than to actually protect against serious attacks.

References. For more details of the experiment I summarized above, read the following research paper:

The Emperor's New Security Indicators.  Stuart E. Schechter, Rachna Dhamija, Andy Ozment, and Ian Fischer.  IEEE Security & Privacy 2007.


Is spam more likely to be sent to info@example.com? Would I be better off using a different address? I think that when bots gather domain names or process a list of domain names, they create email addresses like info@example.com or support@example.com.
Does selecting something different help to prevent incoming spam email? Does it affect it at all?

I have a domain named www.example.com and I want to create an email address for contacting my customers. I was thinking of using info@example.com, but I suspect that such email addresses are very public, hence some software can produce email address based on domain names. Would it be better to create an email address with something different than info@example.com?

So it sounds like you're asking if a some emails are more likely to be spammed than others. I suspect that the primary source of emails for spams is bots collecting any emails you mention on your site. Therefore spam bots will pick up "support@example.com" just as often as "randomgiberish@example.com?". In any case you should rely on your spam filter to do it's job and use the more professional email.


Nonce construction for CTR mode (Mcrypt) Edit: I'll put up this more clearly.

By the most simplest form, I'm asking that if I AES encrypt in CTR more with Mcrypt (using PHP), can I create the "IV" by just simply reading 16 bytes from /dev/urandom? Does that do the job properly?

I read the previous answer by D.W. and he said:

"In the simplest form, to encrypt a n-block message under the IV v, we use v, v+1, v+2, .., v+n-1 as the counters, so let me assume that's what you are doing (if not, please specify). Generating a random 128-bit counter using /dev/urandom is fine."

Now I'm asking that did I understand that answer right (my understanding is that if using CTR mode, one can create the "IV" by just reading from /dev/urandom and that about it)?

I split up this question from TCrypto - Comments about design decisions I made?

@D.W. "It depends which variant of CTR mode you use, and how the counter is formed. In the simplest form, to encrypt a n-block message under the IV v, we use v, v+1, v+2, .., v+_n_-1 as the counters, so let me assume that's what you are doing (if not, please specify). Generating a random 128-bit counter using /dev/urandom is fine."

I was looking at this and I'm not sure if Mcrypt already does that "v+1, v+2..." nonce construction internally (using the supplied IV). Basically Mcrypt takes a key and an IV and performs the encrytption using those parameters.

Or do I have to manually split the message into chunks and perform the encryption for the first chunk using the IV, then encrypt the second chunk using IV+1 as the IV etc?

Here is the encryption function (in CBC mode, Mcrypt's interface to use CTR mode is similar):

https://github.com/timoh6/TCrypto/blob/master/library/TCrypto/CryptoHandler/McryptAes256Cbc.php#LC31

Your question is very confusing. It does look like mcrypt_create_iv will use /dev/urandom if you call it with MCRYPT_DEV_URANDO. It also looks like you do not need to specify the counter value and you only need to call mcrypt_generic once.


My website got blacklisted as "phishing". Any hints on how to avoid that? I have a personal website hosted using my provider's DNS name (i.e. myname.provider.com) on my personal hardware at home. The web server (both HTTP and HTTPS) is Apache on Debian Wheezy (which is rather dated), but I update it regularly. It has an OwnClound instance, a simple PHP form to send an SMS to my phone and my wife's, and a photo gallery with some art stuff my wife made. The site has an up to date Letsencrypt certificate. There's also an open SSH port for remote maintenance.

Recently, this website got classified as 'phishing' by Blue Coat Web Filter list, so neither me nor my wife can access it at work. Using the tool from this post shows no further problems.

I'm thinking about sending them a review request, but before I do, I would like to understand what could have gotten me blacklisted in the first place, to see if I can fix the problem beforehand. Is this because of OwnCloud? Web gallery? Letsencrypt certificate? Provider's DNS? Dated Apache? Open SSH port? Or do they just blacklists all URLs starting with 'D' because it's February?

What are the most common red flags which are used to blacklist websites?

This is not an answer but rather an experience I have been through when our company blocked websites like yours. What normally happened was that the legit site was vulnerable to a vulnerability called Cross Site Scripting.

Basically what it does is use your site for phishing attacks such as stealing passwords and usernames and etc. This is just a possibility because there is not any information on this case and I believe that your site was pointed out  to be this way and someone has falled into the attack.

If this happened what would we do.

Trigger a command called whois and report to the email provided.
Wait for a time and investigate if it is really still there.
If not tell the sites provider (e.g. HostGator) and the providers initiated the takedown.

What should you do.... If this happened.

Crawl your website and see if there is any auckward page  that you did not make someone could have access to the sites password entered and put a page for phishing.very good technique because you site is a good domain.
Use a Security scanner like openvas and search for security vulnerabilities such as related above
If any of this happened switch the sites password and patch all vulnerabilities including if you use opensource.

Then again a suggestion.


Yubikey: How is the OpenPGP key secured by PIN and passphrase? Using the Yubikey 4 as an OpenPGP smartcard with GnuPG: How is the user PIN and user passphrase secured?

In case a sophisticated attacker with physical access to the Yubikey 4 manages to physicaly extract the private-key under the microscope without knowing the user PIN and user passphrase:

What encryption (cipher, mode, hashing, etc.) is in place at this "last resort" to protect the private-key?
Is this very last cryptographic barrier made from GnuPG code or does the Yubikey manufacturer coded his own version?

Since Yubikey 4 states its a compatible OpenPGP smartcard  - does it mean it has the same PIN/passphrase protection as the G10 Smartcard?

Given there was a bug allowing you to use the private key without the PIN (passphrase) being validated, I derive the card does not actually encrypt the private keys (like it would have been done when using "normal" keys with passphrase protection with GnuPG):

  The source code contains a logical flaw related to user PIN (aka PW1) verification that allows an attacker with local host privileges and/or physical proximity (NFC) to perform security operations without knowledge of the user’s PIN code.

I'm not aware this changed, but only the verification was fixed in current releases. With other words, the secret keys on a YubiKey are stored unencrypted, and sophisticated attackers able to read the key's storage are able to extract the unencrypted private keys.


ssh public/private key pair I am having problems understanding how ssh really works. I know it uses a public key cryptography to encrypt messages. However, I can ssh to a server without first generating a public/private key pair for me. I checked my .ssh folder and there is no .pub file there so I assume I have no public key that the server is aware of. So how can the server send me an encrypted message if I have no public key in the first place?

As @klaustopher describes, the SSH tunnel uses a Diffie-Hellman key exchange, to establish a shared secret between client and server; this shared secret is used with symmetric cryptography to encrypt and check integrity of all subsequently exchanged data.

As itself, DH+symmetric crypto is fine, but it does only half of the job. When the DH protocol has been executed, the both client and server know that they now have a secure tunnel with... someone. But they do not know who. They just know that this will be the same entity throughout the lifetime of the connection. So this is vulnerable to active attackers who impersonate the client, the server, or both. The famous Man-in-the-Middle attack is a case of double impersonation (the attacker acts as a fake server when he talks to the client, and as a fake client when he talks to the server).

To make a completely secure tunnel safe for transmitting confidential data and sensitive commands, the client and server must authenticate each other. In the first steps of the protocol, the server signs what he sends (his half of the Diffie-Hellman protocol); the client verifies that signature with regards to the known server public key (the one the client stores in .ssh/known_hosts). Once the signature as been verified, the client knows that it is doing the DH key exchange with the genuine server, not an attacker posing as the intended server. This means that the client can safely send confidential data over the tunnel. In particular, once the DH has been done, the first exchanges go thus:

(server) Ok, new client. We did the DH, I signed, you verified, you know I am the rightful server. Who are you ?
(client) I'm Bob.
(server) Prove it !
(client) Here is my password: bobisthemasteroftheuniverse
(server) Ok, I do know of a "Bob" user, and that's the right password. Welcome, Bob.

Thanks to the authentication of the server by the client (through the signature verification algorithm), the client knows that it can safely send his password in the tunnel.

The SSH protocol also supports signature-based client authentication. The DH and signature by the server are still done as previously. But the protocol then goes thus:

(server) Ok, new client. We did the DH, I signed, you verified, you know I am the rightful server. Who are you ?
(client) I'm Bob. I have a key pair ! The public key id is: (...)
(server) Yeah, let's see to that. Here is a bunch of random data, I challenge you to sign it: (...)
(client) Here is a freshly generated signature on your challenge: (...)
(server) Good. I know of a "Bob", his .ssh/authorized_keys contains a public key matching the id you sent, and your signature on my challenge verifies correctly with regards to that public key. Welcome, Bob.

More or less the same thing happens with HTTPS. There are many local differences, e.g. the HTTPS client recognizes the server public key by validating a certificate instead of remembering it from a previous visit; and the password thing can take the form of actual Web pages; but the gist of the exchange is the same: the client makes sure that it talks to the right server by verifying its public key, and then the server makes sure that it talks to the right client (if the server is really interested in knowing who is the client) by running some sort of authentication protocol within the tunnel.


Repercussions of disabling sockets in Adobe Flash player? I am bit of a newbie to Flash exploits but I have heard that they use sockets to connect to a C&C server. According to the administration guide, I can disable sockets like this:

DisableSockets = 1

This option enables or disables the use of the Socket.connect() and
XMLSocket.connect() methods. I want to know what could be issues around it?

The issues that I am looking for, specifically, are if I harden by disabling sockets, will our existing SWFs work or not?

No issues with disabling sockets. You can always whitelist socket connections

EnableSocketsTo = [ host name, IP address ]

if you have any whitelisted application using socket.connect. nothing breaks that way...


Can someone bruteforce my OSX? (Macbook) Is it possible for someone to bruteforce or perform a dictionary attack on a Macbook?

It's very easy to bypass security of a Windows box (Password Protection) , what is the difficulty level of bypassing the security of a mac running OSX.

Can someone run forensics on it and recover data without knowing the password?

Sure, John the Ripper for example and other tools can crack the passwords.

Always choose a secure and random password.

Bruteforcing applies to any OS.

You can encrypt partitions and complete disks.

Without any secure encryption anyone can read the data from the disk with the right tools. There are great opensource IT forensic tools available.

There are also known bruteforce attacks on the EFI PIN and iCloud lock used for locking the device.


Multiple Open ports on a server, is that safe? Using nmap I try to scan a server as a result I get multiple open ports.
For example when I try to scan domain.com as a result:

7/tcp open echo
9/tcp open discard
13/tcp open daytime
21/tcp filtered ftp
22/tcp filtered ssh
23/tcp open telnet
25/tcp open smtp
26/tcp open rsftp
37/tcp open time
53/tcp filtered domain
79/tcp open finger
80/tcp open http
81/tcp open hosts2-ns
88/tcp open kerberos-sec
106/tcp open pop3pw
110/tcp open pop3
111/tcp open rpcbind
113/tcp open ident
119/tcp open nntp
135/tcp open msrpc
139/tcp open netbios-ssn
143/tcp open imap
144/tcp open news
179/tcp filtered bgp
199/tcp open smux
389/tcp open ldap
427/tcp open svrloc
443/tcp open https
444/tcp open snpp
445/tcp open microsoft-ds
465/tcp open smtps
513/tcp open login
514/tcp open shell
515/tcp open printer
543/tcp open klogin
544/tcp open kshell
548/tcp open afp
554/tcp open rtsp
587/tcp open submission
631/tcp open ipp
646/tcp open ldp
873/tcp open rsync
990/tcp open ftps
993/tcp open imaps
995/tcp open pop3s
1025/tcp open NFS-or-IIS
1026/tcp open LSA-or-nterm
1027/tcp open IIS
1028/tcp open unknown
1029/tcp open ms-lsa
1110/tcp open nfsd-status
1433/tcp open ms-sql-s
1720/tcp open h323q931
1723/tcp open pptp
1755/tcp open wms
1900/tcp open upnp
2000/tcp open cisco-sccp
2001/tcp open dc
2049/tcp open nfs
2121/tcp open ccproxy-ftp
2717/tcp open pn-requester
3000/tcp filtered ppp

and much more other open ports.

I want to know if these open ports have dangerous impact?

It's possible to exploit these services behind open ports?

There are a lot of misunderstandings and assumptions in your question, but I will try to address them.

First, you are scanning a domain (I assume from the Internet). Just because nmap shows them as open does not mean that they actually are. There are a lot of devices in between you and the domain that could be responding to the scan, and they might just be responding to anything you send them without actually having the service running.

Second, just having a service running is not bad. Having more services running than you need just opens you up to a greater range of threats for no reason, so the advice is to only expose the services you absolutely need.

Third, "is it possible to exploit these services behind open ports" is the wrong question. It's like asking if a door you are looking at across the street is unlocked or not. There is no way to tell just by knowing that there is a door. You need more info.


WPA2-Enterprise certs vs HTTPS certs I was trying to download the certificate for a WPA2-Enterpise network I was connecting to. However, when I clicked on the link to install it, the browser said the cert was already installed as a CA. This being a certificate to identify wifi networks, why is it being trusted by the browser for https connection?  Also, I have never opted to trust this certificate for http-TLS connections before on this machine, which is why I found it strange that the browser was trusting it to begin with. The browser is Firefox.

The story makes sense up to the point you mentioned Firefox. Certificates are shared between applications by the operating system, this is the case for both Linux and Windows. Firefox has its own certificate store, because they have their vision to what is trusted and not. However Firefox can be configured to trust the OS shipped certificates as well. This would make sense since you have to install the certificate in order to connect to a network. Firefox then accepted the HTTPS because it was already present in the OS.


Is a predictable MAC address a risk? If you knew from the public internet that a certain IP address belonged to a machine with a certain MAC address, can you see any security exposure associated with that? I know that some software will use a MAC address as an identifier, but I can't think of any security risks associated.

Context: static DHCP assignments for virtual machines where addresses / MAC pairs are pre-generated and the same for all software installations (e.g., any VM being assigned 192.168.1.1 will have the same MAC address).

MACs are predictable in many existing environments. For example, on a typical enterprise network, you're likely to find many physical machine that are part of the same shipment from the same manufacturer and therefore have similar MACs (same OUI and consecutive low-order portion). Any system whose security depended on unpredictable MACs would fail in a typical enterprise environment.

Tying the IP address with the MAC might reveal something about the manufacturer, the type of device or the role of the device that's behind a certain address. That's unlikely to reveal anything that nmap wouldn't reveal, and for virtual machines I don't see how this would reveal anything. On the contrary, if you're worried about your network architecture being exposed, using the same naming scheme for both reduces the amount of information you're revealing (not that the MAC addresses are very likely to turn up on the outside anyway).

If your machines migrate over externally-distinguishable networks, then a MAC address becomes an identifying element and therefore a privacy concern. But in that case they'd likely change IPv4 addresses as they migrate. Tying the MAC to the dynamic IP address (if you somehow manage that — standard DHCP wouldn't apply) would increase the privacy in that case.


IS TDE PCI-Compliant? According to PCI PAN can be stored in the database as long as strong cryptography is used. I couldn't find which cryptography is considered strong according to PCI. Here's the issue: I have PAN numbers stored as clear text in one of my databases, these numbers are gathered from a specific application (with set access rights) to generate reports. The thing is, currently, anyone accessing the SQL database can view or maybe copy the numbers as clear text. What i was told about TDE is that anyone accessing the database from inside our network can still view the numbers as clear text, and only if the database was copied to the outside, these numbers will be encrypted. My questions are the following: Is it okay by PCI standard that a database administrator can view the numbers clearly even if the database was TDE encrypted? Can an SQL Database be encrypted by other means (DES maybe?) so that the numbers can only be visible from inside the application and everyone accessing the DB will view encrypted data only?

I am assuming that you are here talking about the "TDE" feature provided by Microsoft SQL Server.

TDE means Transparent Data Encryption, emphasis on "transparent". This is an encryption layer applied on data as it is stored; every single byte that SQL Server manages is encrypted before being written on disk, and decrypted when read. Applications which use SQL Server need not be aware of that process; it is a matter which resides purely in the dialogue between SQL Server and its storage files. Hence the transparency. The nice side of it is that it is easy to apply, and performs very well (small to negligible CPU overhead, no extra I/O, no extra space...). The dark side is that SQL Server itself, not the application, is the gatekeeper: whoever is granted access by SQL Server will be able to see the clear data.

For PCI compliance, see this document which includes this paragraph (at the end):

  Some cryptography solutions encrypt specific fields of informatio
  n stored in a database; others
  encrypt a singular file or even the entire disk where data is stored. If full-disk encryption is used,
  logical access must be managed independently of native operating system access control
  mechanisms. Decryption keys must not be tied to user accounts. Encryption keys used for
  encryption of cardholder data must be protected against both disclosure and misuse. All key
  management processes and procedures for keys used for encryption of cardholder data must be
  fully documented and implemented. For more details, see PCI DSS Requirement 3.

"Full-disk encryption" is what applies to TDE (TDE is nominally applied on files, but all of them). In TDE, the actual encryption key is managed by SQL Server, who will grant or not-grant logical access to users based on... its configuration, which may or may not map on user accounts. So I would say that whether TDE grants PCI compliance depends on how it is used.

I am not entitled to give a definitive answer on how PCI compliance can be achieved with TDE, but I note that the Wikipedia page includes an encouraging excerpt: "Enterprises typically employ TDE to solve compliance issues such as PCI DSS." So it can be surmised that meeting PCI requirements with TDE is possible, or at least many people appear firmly convinced that it is possible, which is almost as good.

Microsoft has documentation on how SQL Server should be configured and used in a compliance context. They also have a Webcast which may include a lot of useful information (I have not viewed it).


There are two copies of the header data, not just the JSON but also the preceding binary header. This is very common in storage formats. The reason is resilience against failures while writing the header data, for example a power loss. If updating one of the copies of the header fails, the other copy is still valid. When the driver mounts the volume, it reads both copies, and picks the most recent one if both are valid.

In the case of LUKS2, see the LUKS2 on-disk format specification for details. In §2 “LUKS2 On-Disk Format”:

  The binary and JSON areas are stored twice on the device (primary and
  secondary header) and under normal circumstances contain same functional
  metadata.

See §4.5 “Metadata Recovery” for what a LUKS2 driver does when mounting a volume where the headers have different content. The format specification doesn't mandate a particular procedure to update the header, so while a header update is in progress, either the first copy or the second copy may be the most recent one. The most recent copy (assuming both are in a valid state) is the one whose seqid field is larger. The seqid field is at byte offsets 16..23 in the binary header (see §2.1 ”Binary Header“). In the example you posted, the two copies are identical (as expected in normal operation), both at seqid=3.


Is "user education" actually doable? I was going to ask about how to educate users, but now that I think about it, I first want to know if it's actually possible to do effectively at all.

Are there any amazing success (or horrible failure) stories floating around about user education, and different approaches thereto? Any statistics on whether companies that attempt to educate their user base about computer secure are, in fact, less likely to suffer a major compromise?

My own experience is that people are often unwilling to alter their usage habits - especially more knowledgeable end users, who assume they know enough to avoid compromise. But my experience here is pretty limited, and based mostly on home/desktop use rather than office/workstation. I'm interested in hearing how this stuff plays out on a larger scale.

I don't have any documented examples or statistics, but I can say that while difficult and expensive, it is certainly possible to educate users. It's easy enough to have security awareness training and whatnot, but the real problem lies in enforcing the policies and auditing their effectiveness. The most successful compromise controls are technical because it doesn't give people a choice. Not letting someone log in until they change their password is much more effective than having someone sign a sheet of paper saying they'll change their password every 90 days. Many other vulnerabilities stem from things you can't control through technical means. Such as phishing.

In order for education of users to be truly successful the results have to be observed and policies need to be enforced, regular reviews need to take place and there needs to be repercussions for not following policy/training. Just because it's hard or expensive doesn't mean it shouldn't be done at all though. Doing nothing in the way of educating your users will almost certainly be worse than at least making sure employees are aware of the risks involved with their various behaviors.


German police malware "Staatstrojaner" general question In the case of the recent find by CCC, how exactly would the malware used by German police for internet wiretapping work? In default mode, it takes screenshots of active windows, it logs data and forwards the data for remote pickup. It is also capable of spying on Skype, and messenger conversations, and executing code on the infected machine. Would this be an example of a rootkit? How would it be installed? How would you detect such malware if AntiVirus don't pick it up.

From the article, here's my understanding:

The core of this malware is a dll that registers itself to start up on boot, and a kernel module that allows the dll to access kernel-level function that it would not otherwise have access to. Once running, the program listens for incoming commands; depending on the command, it can do a number of things - take a screenshot, record a screencast, etc.; most of these do not require root permissions.

Spying on skype and e-mail happens through user-level API calls - it's as simple as grabbing screenshots and recording audio from the sound card's mix bus. The resulting data is sent back, with AES encryption applied (but in a way that makes the entire encryption process useless - they use a symmetric key, which is hard-coded into the executable, and has been published by the CCC; anyone possessing this key can now easily spoof responses, with no way of checking whether they're genuine.) Another delicate detail is that since the malware mainly spies on local things - it can take a screenshot of an e-mail you're currently writing, and post it back home, regardless of whether you actually send the e-mail or delete it.

There is also a command to download and execute arbitrary code, with full administrator permissions, and this part requires root-level access (otherwise the user would be presented with the usual UAC prompt, exposing the malware).

So yes, the malware contains some kind of root kit, but most of its functionality can be achieved without it.

EDIT:
Note the second update by CCC, now 2 years old, for mentioning the discovery of a new software version. It was published three weeks after the first update already linked to from a comment below.


How is generating payment Tokens secure in Mobile development? I'm using Stripe for in app payments in my mobile app project and I don't quite understand how any app is secure if the user inputs there card info (with or without stripe) if it's not over HTTPS the whole time.

From my understanding if you want to do any form (pun intended) of payments on a mobile device you have to create a token and send that token to a backend server that uses HTTPS  (and has the private-key) to process said payment (with stripe, I'm not familiar enough with the others).

As stated by stripe:

  It's worth noting that Checkout doesn't actually create charges—it only creates tokens. You can use those tokens to create the actual charge on your server.

Where the token turns into a charge when it's on the server-side that's over SSL

  All submissions of payment info using Checkout are made via a secure HTTPS connection. However, in order to protect yourself from certain forms of man-in-the-middle attacks, we suggest that you also serve the page containing the payment form with HTTPS as well. This means that any page that a Checkout form may exist on should start with https:// rather than just http://.

My Question/Concern (TL;DR):

So you can create a token without without having it be over HTTPS, where it is only the payment that needs to be over HTTPS.
However, is this token creation process secure (my first question)? I cannot help to think that anyone entering their card information where there information is sent over the wire to stripe and back to create a token is not secure and is prone to man in the middle attacks.

Is it secure for token be created over HTTP and not HTTPS? Is it secure to then send that created token over the wire using HTTP?
If so, couldn't the user's card info be jeopardized (e.g collected or scraped) in this process? As the card info being entered, sent to stripe, sent back, and then sent serverside all without HTTPS?
What are the best practices when dealing when mobile? Does this case differ in native or hybrid development? What about using in app browser for payments?

You seem to have a misunderstanding about token creation, when you say you can create a token without having it be over HTTPS.  Token creation goes as follows:

Cardholder submits card over HTTPS to Stripe
Stripe stores the card number and associates it with a token which they generate
Stripe hands the token to the merchant (you).
From then on, you can charge the underlying credit card by telling Stripe to charge that token.

Step 1, where the card number is transmitted across the network, must be protected by HTTPS.  The token, while not as sensitive as the card number, is usually transmitted over HTTPS also.

When Stripe says

  we suggest that you also serve the page containing the payment form
  with HTTPS

They mean that your page which contains the form (or iframe, or link, or javascript) that leads to Stripe.  They're not talking about subsequent token transmissions when they say this (although, again, standard practice is to protect the token as well).

To answer your questions:

  Is it secure for token be created over HTTP and not HTTPS?

No.  Token creation requires card data be transmitted, which requires HTTPS as per PCI.  Remember, you don't create the token, Stripe does, and they're at the other end of the Internet from both you and your customer.

  If so, couldn't the user's card info be jeopardized (e.g collected or scraped) in this process?

Since #1 is "no" the "if so" clause doesn't apply.  (Yes, if you didn't use HTTPS, the user's card info could be jeopardized, which is why it must be HTTPS.)

  What are the best practices when dealing when mobile?

Best practice is to encrypt everything, on or off mobile.


Choosing an SSL certificate provider Does it make any difference which provider I get my SSL/TLS certificate from? In particular, what are the pros and cons getting an SSL certificate from Verisign vs getting one from Thawte? Which one can be used on more devices?

According to Verisign, it is best to buy your certificates from Verisign, because then the obtention fee goes into Verisign's pocket, and not Thawte's pocket. Understandingly, Thawte's point of view somewhat differs.

Since they both comply to the same standard (X.509), there's no problem in using a certificate from either in any kind of device. What could make a CA a better choice than any other is:

whether one CA could get its root public key included in most OS and Web browsers by default, and not the other;
whether one CA has an easier to use issuing procedure;
whether one CA asks for less money per certificate than the other.

In practice, Verisign and Thawte are quite on par with each other for all these criteria, so you may choose the one which has the Web site colours which please you most, or whatever. If you really must make a choice, it won't be technical, rather legal: which one offers the best financial guarantees if a mishap occurs ? See with your legal department, then.


How are leaked government credentials possible and what's the point? In the wake of all these leaked/stolen/hacked government login/passwords being stolen it got me thinking.

How is the leaking of these passwords even possible? Or are they of any real use?

Aren't all these passwords hashed or encrypted somehow? Unless the passwords are stored in plaintext what's the point in even trying to steal them in the first place?

What's the point of stealing hashed passwords?
Let's say I steal a hashed password, I can take a random string, hash it, and see if the hashes match. If they do then I've just cracked your password.
For example, assume that under some hash function we get the following hash table:
"cat" --> AA
"dog" --> AB
"elephant" --> AC
...

If I steal a password database and see that your hashed password is AB then I know that the plaintext password is "dog". (technically, more than one string will hash to "AB", but since the server is comparing hashes, not raw passwords, any of them will let me in. So in effect your account has multiple passwords; any string which hashes to "AB" is a valid password for your account.).
Attackers can crack hashed passwords by pre-computing hashes for large numbers of potential passwords (usually obtained by combining dictionary words, or from lists of previously cracked passwords), and then using this as a lookup table to convert hashes back into plaintext passwords.
This kind of attack is generically referred to as a Rainbow Table Attack, with introductory explanations here and here.
One issue with rainbow tables is that to cover any reasonable number of candidate passwords, the size of this lookup table grows to terabytes and requires multiple hard drives just to store it. As you can imagine, attackers have developed fancy tricks for optimizing the reverse-hashing process, so while the general idea of rainbow tables is simple, actual optimized implementations get very complicated very quickly.

It's worth mentioning a few of the common counter-measures that db admins and developers use against rainbow table attacks.

salting is the trick of appending a random string (the 'salt') to the raw password before hashing it. Each user has a unique salt which means that, in effect, each user uses their own unique hash function, so an attacker can't re-use rainbow tables and has to pre-compute a brand new table for each user.

Take the password and run it through a large number of salt-and-hash iterations of a strong cryptographic hash function before storing it in the db (for example, 100,000 iterations of SHA-2), which makes it much more expensive to pre-compute the rainbow tables. It also makes it slower for users to log in.

Use a hash function which takes in a private key (these hash functions are called HMACs). The idea is to use a private-key known only to the server in computing the hashes so that it's impossible to compute a rainbow table without knowing the key. The problem with this is that when an attacker has enough access to steal a whole database, they can usually steal the private key as well.

In your question you also mention storing encrypted passwords. This is similar to 3. in that, unless you have a good way to protect the encryption key (for example, dedicated hardware like an HSM), then the attacker will steal the key along with the database.


Reasons to transition Kerberos secured web applications to OAuth2/OpenId We have five internal web applications written in Java  / AngularJs that are secured via Kerberos/ Spnego ( Spring Security implementation) . We are looking to transition these apps to AWS ( EBS) .

I am building a business case to convince the management why I should rewrite the auth. on these apps to use OAuth2/OpenId . Looks like Kerberos is supported via Amazon EMR.. or at the worst we just provision another EC2 with a domain controller.  What are my considerations , pros and cons.

pros;

oauth works from computers not in your domain.

cons;

oauth works from computers not in your domain
extra development work
need to login to more than just the OS.


Why do websites show parts of phone numbers, but never email addresses? Say that I have a website that allows for a user to reset his password through either email or via text message. The user should be allowed to choose one or the other.

Without giving away too much information, what would be the optimal amount of characters to display for a phone number and for an email address to allow the user to reset their password?

Most sites that I've come across don't display emails at all (knowing only a few characters could help an attacker link an email to an account), and just send a reset email silently. But phone numbers seem to be treated differently, as sites tend to display at least part of phone numbers, often using the last two characters of the number like so:
(***)-***-**55

Is this the best convention to follow in terms of balancing usability and security? Why do websites display any part of a phone number when they don't display emails, and is there any associated risk with displaying that the user has a phone and/or email connected to their account in the first place?

This is all based upon the design of the website.

E-mail address is commonly used for username for your account. So, if the website exposed few characters from the e-mail address then it's few less characters to brute force. If the website does not use e-mail for account name then it's narrows down attack for social engineer or other forms of attacks.

Phone number is not commonly used for the username, so exposing this doesn't have an direct threat towards compromising an account on the website.


How can I protect the signup form in my website? Is special spam prevention needed? I'm struggling to write a  secure sign-up form for my website. (My site is some kind of an image gallery. I have knowledge in html, javascript, msql and php)

I know there is a tactic to secure login forms via checking and storing the failed login attempts, but do I need to protect my sign-up form in the same way? (Is it a stupid idea to log sign up submissions and ban ip-s if someone sends too many requests?) Will someone "spam register" my sign up form? Is it a common attack?

At first i was thinking about using ReCaptcha, but many sites says it's not necessary in this case and it's very annoying for normal (human) users.

My second thought was a database table: storing user ip-s and sign up attempts, to prevent too many registrations, but it's not 'too much' security? (My main concern about this is the constant database checking/writing process because it uses resources)

PS: my system send an e-mail confirmation request before letting users in, but still not confirmed users will be registered in the database so (if i want to) i can register hundreds of fake users (with some kind of a automated program) just for fun which is bad.

You may want to try Invisible ReCaptcha. It should be the best compromise between security and convenience. Normal ReCaptchaV2 is also simple enough, if you need more security.


If I send 4mbps of data to a friend with 4mbps connection, will I DoS him? Suppose my friend has a connection of 4mbps. If I just send him 4mpbs of random data with my server, wouldn't it block his connection? Even if the router has firewalls and closed ports, isn't enough for me to send random data continuosly to his router, in order to block it?

I've found some scripts on the internet (like this) and I tried to block my own connection with my server, but nothing happened.

Assuming you're just throwing data at a closed port, your friend will notice a substantial slowdown in his Internet connectivity and an increase in packet loss, but it will not result in an inability to use the Internet.

Think of his connection as a pipe: you're trying to throw 4Mbps down a 4Mbps pipe, and he's trying to pull additional data down.  Something has to give, and it happens in the form of dropped packets.  The packets to drop are selected randomly, and since most of the packets are your attack packets, they will also constitute most of the dropped packets.  Packets he wants will get through often enough for the connection to be somewhat usable.

In order to perform a bandwidth-starvation attack of the sort you're describing, you need to throw far more data than the target can handle, so that almost all of the data the target wants gets dropped.

(Terminology note: this is a DoS, not a Distributed DoS, since you're only attacking from one location.)


Am I being Hacked? So many defferent ip's in router firewall logs My router dsl light was not stable; It keept disconnecting and connecting..So I logged into Router Homepage to check whats wrong and found there were so many different ip's in Router firewall logs I dont even know of..there was a log for every second..How do i stay secure..Im really scared, am I being hacked?

Unfortunately attackers scan the internet and are looking for vulnerable systems which they can exploit and then misuse to attack other systems - see for example this information about the VPNFilter botnet exploiting routers or this information about the Satori botnet infecting routers.

Thus, it is very likely that somebody is trying to attack your system. There is nothing you can do against somebody trying to attack you, but you can do something to make sure that the attacker does not succeed. This means especially to not use a router with known vulnerabilities or backdoors, with known default passwords or with weak passwords.

There are several information at this site which can help you with securing your router, for example Best practice for home router configuration, How to recommend a (more) secure router, Are consumer-grade routers any more or less vulnerable? or How to secure a router/modem?.


Remote Access Trojan (RAT) -- How to detect, how to remove Is there a guaranteed way to:

Know there is a Remote Access Trojan in my PC?

Remove it completely and successfully from my PC?

Note: Assume that the hacker doesn't leave any hint of their activity (like moving the cursor).

If there is no way to detect or remove RAT with 100% guarantee, what other ways could guarantee that my computer is out of danger (is not compromised)?

There are no 100% guarantees.
Proving a negative is basically impossible. It's like saying "How can I prove that nobody owns a key to my apartment?" - you simply can't.
However, you can detect certain remote access kits through a variety of techniques. Keep in mind that these techniques require some level of expertise. People often say "Look at your network traffic", and then they go buy a tap, have a look in Wireshark and see lots of network traffic to various domains and IP addresses they cannot explain and then end up believing they must have been compromised. I personally label this the "Wireshark Syndrome". However, the underlying idea is correct - look for suspicious traffic and investigate further. This requires you to be able to tell suspicious traffic apart from benign traffic, which is very difficult.
Another possibility is to use a ready-made tool for RAT detection. These tools look for traces of know RATs and give you a warning should it find some. The upside of these is that they are a lot more user-friendly, but with the downside that they also cannot 100% detect every RAT out there. "I couldn't find anything" does not mean "There is nothing", after all.

How can it be removed from my PC?

The question Help! My home PC has been infected by a virus! What do I do now? goes into detail on how to deal with a compromised home machine.
tl;dr: Nuke it from orbit!

How can I make sure my PC is safe?

As mentioned above, you can't. What you can is follow best practices, that are repeated over and over again by security experts:

Keep your system up-to-date
Don't install software from untrustworthy sources
Use a password manager
Make backups on an external device
Don't click on links in phishing emails and don't answer them.

Of course, this list isn't exhaustive, but if you follow these guidelines, you will likely not be "low-hanging fruit", and that already gets you out of a lot of trouble.


Comprehensive book to study about wireless technology I am searching for a comprehensive book on wireless technology that covers in detail almost everything about wireless technology, including the related protocols, security, hacks, etc. I know it is not possible to cover this in a single book. Can you suggest a basic book to start with, and then books to go to the next level? I want to make my career in the field of wireless security.

Start with this: Wireless Security Know it All

Is focused on the security aspect but it also goes deep in many other theoretical topics, like protocols, signal theory etc.


Is it possible to distinguish between a SHA256 hash and an ecc256 key? If an attacker were just given 256 bits, and they were either a SHA256 hash or a 256 bit elliptic curve key, would they be able to tell which one it is?

Just out of curiosity, would they be able to tell the difference between the above and an AES256 encrypted block, or a 256 bit ECDSA signature?

Your main assumption that key size is directly related to the format of the keys, parameters or output size does not hold.

Normally the attacker would only have access to a public EC key, which is (usually) not 256 bit, but a point on the curve. This point consists of two coordinate values prefixed with an indicator (compressed or uncompressed points).

Usually a key - public or private - would be encoded using some kind of ASN.1 DER structure (PKCS#8/X9.62). So the format of either keys is usually much larger than the key size. This is different from e.g. symmetric ciphers where the keys just consist of random bits.

ECDSA signatures - just like ECDSA public keys - consist of two components with the (approximate) size of the ECC key size. Usually the signature is ASN.1 DER encoded as well. So it would be pretty easy to distinguish it from a AES256 encrypted block.

All that said, EC private keys (parameter S) are normally fully randomized. And as the output of SHA256 should also look perfectly random to an attacker, there would be nothing to distinguish between the two.

However, if the attacker has access to the key or hash, you would expect that they would also have access to some plaintext/ciphertext combination to verify which algorithm was used.