Regarding Openssl.config file: What is the importance of policy matching when creating a self-signed certificate with the aid of this file? When trying to go through some material for self-signing a certificate, one of the steps required me to set policy conditions in this config file. See: https://www.phildev.net/ssl/opensslconf.html

The idea is that when you select policy_match=match, certain fields in the CA's certificate "must match with the corresponding fields in the client certificate to be signed". Why would a CA's certificate have to have matching fields with a client's certificate?

It all doesn't make sense to me since the client could be an arbitrary entity that has nothing in common with the CA. Can someone explain the scenario in which these would have to match?

It is an arbitrary, administrative decision for the creator of CA what client certificates they want to enable to be signed by the CA.

The policy_match in the following configuration line:

policy          = policy_match

is a chosen name that corresponds to a particular section in the configuration file. That section defines in details each of the

[ policy_match ]
countryName             = match
stateOrProvinceName     = match
localityName            = supplied
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

Each of the DN fields for the client certificate can be assigned to have the same value as the CA (match), be required to be specified (supplied), or be optional (optional).

The same guide suggests another policy that matches your criteria of "the client could be an arbitrary entity that has nothing in common with the CA":

[ policy_anything ]
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

Yet if you wanted to create a CA for your organisation, that would allow issuing only certificates for that part of your organisation you can freely set for example:

policy          = policy_branch_1

[ policy_branch_1 ]
countryName             = match
stateOrProvinceName     = match
localityName            = match
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = supplied

Which would required the issued certificates to have first three DN fields matching the CA's certificate.


Do I need additional encryption on top of HTTPS for a REST API? Let's set up the environment before coming to my question.

We have an web application which will be accessible by browsers/clients over HTTPS.
Monstly only accessible in the intranet ( rarely over the internet )
Frontend using Angular
Backend using Java-EE

Now I came to an argument with my colleagues over an concern of mine.

The communication between the frontend and backend is completely unencrypted, resulting in the credentials of a user logging in send over the intranet/internet completely clear text. Also they will enter sensitive data which is a secret of the company (ingredients, proportions, etc.).

Adding the fact we integraded LDAP Login possibility to our application this fact seems highly risky to me, possibly resulting in an entry point to gain more informations off the intranet (getting LDAP credentials and accessing more services and machines).

My colleagues said thats nothing to worry about since the communication between client and server is established over HTTPS.

However they couldn't convince me with only providing that one single argument at all, especially since there are known problems like SSL Stripping, MITM, or even traffic analysis.
I know that I should only worry about those if we don't configure everything correctly, but thats also a concern of mine.

I am on the point that we should encrypt the communication betweeen client and server additionally with something like Jose4J. That would ensure that even in an intranet breach or HTTPS Problem the sensitive data would still be a secret. It would also be more hard to analyse the traffic.

Now I wanted to get an answer which provides more facts and a better conclusion than only "but we are using https".

Is only using HTTPS for an web application dealing with sensitive data "secure" enough?

The communication between the Frontend and Backend is completely unencrypted, resulting in the credentials of a user logging in send over the intranet/internet completely clear text.

  ...the communication between client and server is established over HTTPS.

You are contraditcting yourself. If you are using HTTPS, your data isn't unencrypted.

  ...especially since there are known problems like SSL Stripping, MITM, or even traffic analysis.

SSL stripping is solved by HSTS. Use it. A MITM is exactly what TLS protect against, so I fail to see how that is a "known problem". Not sure what you mean by "traffic analysis", but implementing your own application level crypto is not going to solve it.

I think you are undervaluing what HTTPS gives you.

  Is only using HTTPS for an Web application dealing with sensitive data "secure" enough?

What your question basically boils down to is this: Is transport layer encryption enough, or do I need application layer encryption as well?

For a web app designed to run in the browser, the security value of application layer encryption is basically zero. Why? Because the very code that does the application layer crypto will have to first be transported to the client. If transport layer crypto is broken, that code can be tampered with to the attackers benefit.

And anyway: You do not trust yourself to configure your own TLS. Why should you trust yourself with the much more complex task of setting up safe application layer crypto? I promise, it will be much easier to just read up on TLS and do that right.

Your collegues provided you with only one argument, because it's the right argument. Use HTTPS.


How to make Sqlmap obtain administrator rights for database? I'm using sqlmap to exploit databases in a DVWA-project.

However, after having exploited the database, I executed the following command to learn that the user is dvwa@%:

sqlmap -u "http://192.168.71.130/dvwa/vulnerabilities/sqli/?id=2&Submit=Submit#" -p id --cookie="security=low; PHPSESSID=kikm4b9s9tdk5kq21cs20jt9j1;" --current-user

I'm trying to INSERT something into the tables, with these commands:

sqlmap -u "http://192.168.71.130/dvwa/vulnerabilities/sqli/?id=2&Submit=Submit#" -p id --cookie="security=low; PHPSESSID=kikm4b9s9tdk5kq21cs20jt9j1;" --sql-query="INSERT INTO guestbook (comment,name) VALUES ('foo','bar');"

However, this fails - although a basic SELECT statement works fine.

I guess the dvwa@% user doesn't have privileges to INSERT/UPDATE.

Is it possible for sqlmap to automatically obtain administrator privileges for the database (in this case DVWA)?

1) If you are inserting into a SELECT/UPDATE/DELETE query you can only issue INSERT statements if stacked queries are available (you have to close the original query and start a new SQL statement). This is a limitation of the SQL language.

2) Privilege escalation would require a vulnerability in the database server or one of the stored procedures. Check the server version and look for stored procedures that execute as privileged user (e.g. EXECUTE AS statement in case of SQL Server). After you find a vulnerability you should execute the trigger instructions, which can be problematic if you don't have stacked queries.


How do JavaScript (and mobile) APIs keep user data clean? Let's say we're running Google Analytics, and we're tracking user specific data (or displaying contents based on that data, such as most recently viewed pages) -- we add a pixel, and then we pass the user data to the Analytics platform. What's to prevent a malicious user from passing a bunch of garbage data based on random user ids?

Same thing with mobile; let's say we integrate a customer service SDK such as Zendesk. There's usually either a key or a cert that we have to include in our apps. What's to stop a malicious user from decompiling our app and then using the provided cert in the app, read all user tickets from whatever user id he passes?

And what are things we can do, both as app/web developers and SDK developers to block these types of attacks?

I don't know of any protection mechanism and I have never seen anything in existing web apps. This is kind of an inherent problem of your client sending requests directly to the third party. In this case a tracking/analytics service.

You can try to obfuscate the JavaScript which creates the request but platforms such as Google have a clearly documented API.

There is even a blog post on how to corrupt this data by using the account on another website which also uses Google analytics.

You can try to track users serve side. Certainly when they have been authenticated, you can track the session across requests. But this does not give you as detailed info as you would get with some JavaScript features. Unauthenticated users could keep requesting new sessions and you wouldn't know.

You will never be able to tell with a 100% certainty if your data has been generated by a bot. Someone can also crawl your website or use a tool like selenium to automate certain user behavior. Some metrics like user agent, timing and HTTP headers could help identify these automated visits.


Fiddler Can decrypt https traffic So apparently, a software called fiddler is able to very easily decrypt secure https traffic with a click of a few buttons:
http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/DecryptHTTPS

I know fiddler is a credible piece of software, but surely you cannot just start decrypting secure https traffic using this tool, so easily.

Whats the catch here guys? Is there more to it? is there any requirements?

I just wish to learn more about this.

Thanks.

They are doing a man-in-the-middle attack which needs the user to either ignore security warnings or to explicit import the CA used by fiddler. For more discussion about this topic have a look at How can I prevent a man-in-the-middle (MITM) attack on my Android app API?


Security benefits of running as standard user vs. administrator I heard in a podcast a while back (I believe it was Steve Gibson's Security Now) that running Windows as standard user vs. administrator mitigates 99% of Windows vulnerabilities (I think that was the correct percentage I heard). Anyone have a source to back this up? Also, what is the best way to configure this? What I did on my machine is enable the local admin account and added a strong password to it. I then changed my Microsoft account to standard user. Whenever I need admin permissions, I need to enter the password of the admin account I enabled. Is this the most secure way to enable this?

Also, anyone have any ideas why this is not always configured within.   organizations? I worked in security for a large consulting company, and this never came up. Users always run as admin vs. having to type a password. It seems like this would be the simplest way to drastically improve the security posture of the organization.

In an enterprise environment only a small subset of users should ever have local admin rights if you want the systems to remain secure.

Thankfully, Windows 10 has mitigated some of these issues slightly but even so, the key thing here is that a user with local admin rights has the ability to make changes to the operating system including the installation of new software, changes to existing software and changes to the registry.

When running as a standard user, Windows 10 will not simply throw up a warning box that you have to acknowledge but will throw up a login box into which you have to supply an administrative ID and password.

This dramatically reduces the opportunities for malware to activate or install itself on a system. Which is the main answer to your question.

In addition, running as a standard user in an enterprise environment prevents users from bypassing security controls and generally making a mess of the PC which typically dramatically reduces support costs.

Any organisation running the majority of users with local admin rights is asking for trouble and in regulated industries such as health and finance, this would cause a major audit failure.


Can You Brute Force Dropbox Folder URLs? One can share folders with Dropbox by sending a URL with a hash in it.

A recent article reported that user files were accessed by generating urls from common URL shortners.

These URLs are typically much shorter than the hash url generated by Dropbox.

If you don't password protect the URL there is a non-zero chance that it could be accessed in a random brute force attack on Dropbox.

Would it be statistically possible for someone/botnet to randomly generate the urls and find any content (not necessarily mine). Or are there just too many possibilities available?

EDIT: The news article linked above references a blog post, which in turn references the academic paper.

Can you brute force Dropbox URL? Well, yes, you can also brute force AES256 encrypted file. I think what you are really asking is, would you be successful?

It's quite unlikely. Currently, Dropbox share URL is 11 characters that consists of lowercase alphabets and numbers (36 possible characters). This gives a key space of 36**11 ≈ 1.31621704 × 10^17 possible keys or ln(36**11) / ln(2) ≈ 56.869175 bits.

Now this boils down to a math problem: suppose that there are m occupied keys in a key space of 36**11, if an attacker sends n guesses, what is the probability that at least one of the guesses matches an occupied key.

How many files are in Dropbox that have share URL? I don't think Dropbox published this data, so I'm going to make a guess. Let's say there's 1 billion files with share URL.

If the attacker makes a single guess, he has a 1000000000/36**11 = 7.59753119 × 10**-9 = chance of guessing one key in one guess.

Suppose that the entire Dropbox security response team is on holiday and the attacker managed to make 1 million guesses before Dropbox noticed something's up and shut the attacker down. Then the chance that at least one of the million guesses matches an existing document is 1-(1-1000000000/36**11)**1000000 = 0.00756874289.

Which is about 0.75% chance that the attacker will be able to retrieve a single random file after one million guesses.

In practice though, Dropbox probably have measures to detect and block automated random key requests.


Block request serverside following CORS Should non options requests be blocked if the origin header is not allowed?

I was talking about programming to someone and which led me to tell them about CORS. The person compared it to a gate.

Which in turn led me to look at my code which adds the CORS headers but does not block if the origin is not allowed. Now I get that for options that this is not really doable because it is the check. However, for a POST request, for instance, if the origin is not allowed, should the request be blocked or is already too late at that point?

It is possible that a server does the request, so CORS does not apply at all and no origin is set so it cannot be done. So, this only truly applies to browsers (as far as I know). So, perhaps when this happens the browser is already so far gone that this is already too late.

CORS headers are only honored by supported User Agents (UA from now on). The responsibility of a web developer is to set the appropriate CORS headers for every response, and it will be the responsibility of the UA to enforce such headers and block the access if the headers are going to be violated.

Any request made by the UA will fall in only 1 of 2 categories regarding CORS:

Basic requests that don't require any special treatment
More complex requests that require some special treatment

The process that decides in what category a request ends up depends only on the http request (if it has a payload, the http method, cookies, other headers...) and is decided by the UA and written in the RFC.

If the original request requires some special treatment, then the UA will perform 1 more request before the original http request, that second request has an OPTIONS method to the same URI of the original http request and is only done to get the CORS headers that will apply to the original request in order to make the decision to allow or deny the original request.

Now regarding your questions:

  However, for a POST request, for instance, if the origin is not allowed, should the request be blocked or is already too late at that point?

Since a POST requests is always a request that requires special treatment, it will get denied after the OPTIONS request (also called preflight request) is done if the CORS headers deny the request.

  It is possible that a server does the request, so CORS does not apply at all and no origin is set so it cannot be done.

Yes, if a server is doing a CORS request, then it's his responsibility to honor it since it has become the UA of that http request.

  So, this only truly applies to browsers (as far as I know).

Kind of correct, it applies to any UA that honors CORS headers, and that is usually a browser, but doesn't have to be per se.

  So, perhaps when this happens the browser is already so far gone that this is already too late.

This can never happen for special treatment requests, since a browser that supports CORS will only make a request once the preflight request has allowed him to do so.


What security risks does Firefox 19's built-in PDF reader (pdf.js) bring? Firefox 19 ships with pdf.js as the default PDF reader.

One of the main stated goals is to reduce the exposure of users to the often vulnerable Adobe PDF reader/plugin.

So what new risks does pdf.js bring?

An attacker that can get a user to browse to their malicious PDF could also get the user to browse to a malicious web page. Any vulnerabilities in the HTML5 renderer or javascript interpreters could have been exploited that way anyway.

I actually think the Mozilla devs have been pretty smart with this.

Historically, most PDF exploits have come from the rendering engine rather than the parsing side. Adobe got wise early to the fact that malformed structure and content would screw them, and put a lot of effort into making sure that their parsing engine was rock solid. If you look at some of the recent 0-day stuff for Adobe Reader, you'll see that most of it relies on bugs in the rendering engine and some of the more exotic areas of content handling.

The new Firefox PDF engine simply takes the structure of the PDF and translates it into a DOM structure, which can be rendered by the browser's standard HTML renderer and interacted with via JavaScript. This removes a huge portion of the attack surface, and allows them to entirely focus on the security of the document translation engine. Any real exploitable bugs are likely to be reliant on a secondary bug that could be exploited through other means anyway.

If there are exploits, I see them coming from the following areas:

3rd party objects being loaded into the page, which can then exploit a separate Java / Flash / HTML5 / etc. bug. Probably preventable by using a restrictive content origin policy.
Bypassing content escaping so that arbitrary JavaScript can be executed in the context of the PDF. Again a lot of the significance of this is related to origin policies.
Buffer overflows in any native code responsible for PDF translation. Since most of the engine seems to be based in JavaScript, I'm unsure as to how likely this is.

All in all, I don't think it brings much of an increased security risk, and once it's been around for a few months I'd consider it an ideal drop-in replacement for Adobe PDF plugins, which have been a source of many headaches.


Why is Gbt3fC79ZmMEFUFJ a weak password? On https://passwordsgenerator.net/, it says

  Examples of weak passwords: qwert12345, Gbt3fC79ZmMEFUFJ, 1234567890, 987654321, nortonpassword

The first, third, and fourth examples are obviously weak. I can't, however, see what's weak about the second one.

Indeed, the only problem I see with it at the moment is that it doesn't have any special symbols. Is that enough for a password to be considered weak?

I was curious about the same thing, so I put Gbt3fC79ZmMEFUFJ into Google, and lo! and behold it found something that wasn't just a paraphrase of "Don't use this password" advice — the password itself was embedded in example source code that showed how you could send a password to a server! (link to page, and screenshot below)

So I think the real goal of that advice is not that Gbt3fC79ZmMEFUFJ is a mysteriously weak password because of the keyboard layout or because of low entropy or because it doesn't include symbols or Unicode or emoji or whatever:  It's simply to remind you that you should never use a password that's been published somewhere, especially one published as an "example" password!

[Update: This is intentionally a screenshot and not simply a code snippet; the content of the code is far less important than seeing how it appeared verbatim on somebody's website!]


When to set security questions for a web application? For enhanced security, we can use security questions and use them as a means for users to reset forgotten passwords or as an additional means for authenticating.

When would we be the right time to ask the user select the questions and set the answers?

1- at the time a new user creates a new account with the web application (enter username, password, and answer security questions)?

2- or at the time of first log in (after confirming the e-mail is valid)?

Is there any security and user experience factors to lean to one of these options?

No right answer.

I hate security questions though. Never remember them. Usually fill them with random stuff. If I do need to recover the site, I'll call the company or file a support ticket anyways.

You didn't give enough information to really understand the situation, so here are some options.

Option 1
 1. creates account
 2. confirms email
 3. answers sec questions
 4. Uses site

Option 2
 1. creates account
 2. answers sec questions
 3. confirms email
 4. uses site

Option 1 and 2 are the same. Both questions and confirmation are required before the user can do anything.

Option 3
 1. creates account
 2. Uses site
 3. Tries to do something (save data, print, email, etc)
 4. Forced to confirm email
 5. Forced to answers security questions

I like option 3 if your site supports it. The user can use the site, but you block them from any real functionality until they confirm their email. It gives the user a chance to evaluate the site before committing extra time.

Option 4
1. Creates account
2. Confirms email
3. Uses site
4. Next Login, asked security questions

Option 4 is how gmail approaches extra security features. The present the user with an option to enter phone numbers, and other recovery items. Of course, they don't do security questions. They use phones. Which is a lot less burden on the user.


Application/Octed-Stream header for XML file My application when downloading XML file returns headers:

Content-Type: Application/Octed-Stream
Content-Disposition: attachment; filename=file.xml

Is this behavior correct form security point of view or it should be specified that this is XML file?

that MIME ("Application/Octet-Stream"), used with the Content-Disposition header, simply makes sure that browsers download the url instead of displaying it in the browser. There should not be any security implications of such a configuration. If you want to be able to view the URL online in the browser you can change it's type to "text/xml" or "application/xml".


How to temporarily store data securely on a cache/relay server? Sorry if the question title sounds unclear, I'll happily accept suggestions how to make it better.

Background

We are running a rather complicated SCADA/MES system with a Web interface through which users can, beside other things, set values directly to a PLC control system. The topology is m:1:n, which is many clients to one central server to many control point clients (redundancy/availability measures omitted for simplicity).

Most of the data with which the users interact dwell on the front end server which is secured to the best of our expertise, but is still a web server at the end of the day. We want additional level of security for all actions that don't end their live at the server but are propagated to the control clients.

Current setup is synchronous and direct - on request the server connects direct to the control client and relays the request. The control client has a PIN stored by itself, which is kept nowhere else in the system and distributed to the authorized personnel through different channel. User must supply the correct PIN, or the request gets rejected by the control client

Planned setup

For latency and topology reasons we are planning to switch to asynchronous indirect connection - the request from a user will be stored in the server database and control clients will query the server regularly for the requests. Everything about this setup is convenient, apart from the security implications - the requests for the control points must be stored somewhere on the server, which makes the PIN option irrelevant.

The question is whether there is an option how to secure the 'channel' from the web client to the control client when the requests are asynchronously relayed through the main server.

One idea I could come up with is to simply XOR the request payload, store it on the server and then XOR it again at the control client. This is doable in browser and I suppose this would give the whole request path about the same security as the pin itself. The problem is, that when the Server DB gets compromised and there are more (than one) requests pending in the relay queue, the nature of the requests (JSON strings) will make it very easy to recover the pin. I guess that Base64ing before XOR won't make it any securer.

Details of interest
The requests are in form of very short (max 1 KB) JSON strings. There are max. 1000 control clients and estimated 0 to 5 control requests per control client at any given time. Currently the system is not of much interest to 'third parties' but we don't want to wait to have this assumption refuted.

You do not need to store the PIN on the webserver database, you only need to store something that will enable you to tell (with very high confidence) that the user did input the correct PIN.  Assuming that the PIN is sufficiently long (a twelve digit PIN might work) you could do a classic salt+hash case.

Yet, most PINs are 4 digits, therefore rather useless as an authentication method.  Instead you can use a decent authentication method in addition to the PIN (making the PIN to be just a detail of the authentication).

A hundred thatnks to atk for chasing me on the fact on how much a 4 digit PIN is useless as an authentication and how easy it is to brute-force it.  Seriously, I learned a lot from writing and rewriting this.

Decent option: Add proper authentication

Add a login and password (passphrase) authentication for the users on the webserver.  This authentication can stay only on the webserver.

A user willing to interact with the frontend (at least with the part in which he can alter data) must login first.  Note that if the current webserver setup already performs this you can reuse it for this purpose.

Now that you have a proper authentication (the passphrase) you can store the PIN in the webserver's database based on it.  You can encrypt the PIN under a key generated from the passphrase.  For example using PBKDF2.  In other words, on the first request from a user, the webserver will need to talk to the control system and retrieve the PIN.  It will then store the PIN in the database as follows:

AES(pbkdf2(user_passphrase), PIN)

The user must provide both: his password/passphrase for the webserver and the PIN to perform the request.

On a following request, the user again needs to supply the passphrase and the PIN.  But the webserver can use PBKDF2 on the passphrase and use the generated key to decrypt the record from the database and compare against the provided PIN.

In summary, you add a better security feature (a proper passphrase) in addition to the (quite insecure) PIN.  You can (and probably should) allow the user to change his passphrase on the webserver but then you need a way to invalidate the cached encrypted PIN in the database.

Limited option: Trivial hash+salt

The following is how you could perform this by using a sufficiently long PIN (e.g. an alphanumercial PIN of some 12-20 bytes in length would suffice against today's brute-forcing attacks).  Note that the hash function selection is important.

On a request from the webserver the control system, instead of sending the PIN, may create a salt concatenate to the PIN and use a cryptographic hash to generate a value.  For example the control system may perform something like:

Receives request from server for user Bob;
Generates a random salt (say, 012345667890abcdef);
Retrieves Bob's PIN (say, abdd);
Performs hash <- hash_function(abdd + 012345667890abcdef);
Returns hash and salt to the webserver.

The webserver will store both the salt and the hash in the database.  On a request from Bob to the webserver a PIN will be sent, let's call it reqPIN.  The server can perform the following to check that the PIN is correct:

Retrieve the salt and hash for Bob from the database;
Preform reqHash <- hash_function(reqPIN + salt);
Compare reqHash with the hash from the database.

If the hashes are equal Bob had input the correct PIN.

If the webserver is compromised, you can just boot another one and ask for new salts and hashes from the control client.  Nothing on the webserver database can be used to recover the PIN (not in less than a dozen years of extensive hash crunching at least).

Notes:

The hash_function can be any cryptographic hash and gives you a very small collision chance, which is pretty safe to ignore in practice
Hash functions as bcrypt or scrypt are needed (maybe even argon2), these hash functions are expensive computationally, making a brute-force attack much harder.  You may also perform the hashing several times, i.e. hash_function(hash_function(hash_function(...)))
The salt is needed in case two people have the same PIN and one of them is the attacker.  He cannot tell that the other person has the same PIN as himself even in the possession of all hashes.  He would need all hashes and all salts, and he still would need to recompute all hash iterations.


Torception: An onion within an onion With the recent takedown of silkroad, I am pondering on how anonymous you actually can be on the Tor Network. Other more legal or moral uses such as anonymity as a right, or avoiding censorship. These users do in fact face the same problem if it possible to get through the anonymizing layers of Tor.

Note: I just read the question regarding the reason for silkroad takedown was a leaked IP address. So lets restrict the scope of this question to attacks on the Tor protocol itself, rather than misconfigured http servers...

What my question is, what impact would running "Tor within Tor" make to anonymity, and usability? Would the anonymity (if measurable) be doubled?

To examplify what I mean, the command:

./torify tor

should be enough to run a tor instance where all communication is wrapped inside tor.

Anonymity is not sold by the kilogram. You don't get "twice more" by wrapping Tor within Tor. For that matter, anonymity is not an extensive physical property; it does not add up.

Traffic analysis is the bane of anonymity. It works on counting bytes which enter and exit each machine. The inherent non-anonymity of Web accesses, with regards to powerful eavesdroppers (say, police forces), is not about routers or onions; it comes from user impatience. User clicks on link, then user expects the page to load immediately. Or at least within the next two or three seconds. Under these conditions, traffic analysis can only work well. Going through a lot of Tor nodes does not help much; in fact, it helps mostly insofar as it increases latency, making correlation harder. Wrapping Tor within Tor is equivalent to going through twice as many nodes (so you don't need this wrapping; you can have the same effect by configuring your client to use more nodes; but it won't solve your issue anyway).

There is a kind of immanent justice here: you gain anonymity only through suffering. Being anonymous is only for the deserving.


how to monitor a Wifi (802.11) network? How to capture a sequential stream of data between two machines, making no assumptions about network layer protocols? On wired network, one can do it by ARP spoofing and then sniff the network. One wireless network, could it be possible? Or could one disguise its MAC and receiving data from both S and D at the same time?

In addition, some WiFi has password on it, and some doesn't. It is said that using a WiFi that doesn't have a password is significantly insecure. Why? How could others attack or monitor my activities with a network without password?

One more question. It is said that facilities like airpcap can be used to do such things like monitoring the WiFi network. What is its principles? Could I achieve similar goals without such kind of facilities? (PS: airpcap is fairly not cheap :/ )

You can technically start sniffing away without "connecting" to the network.  Terry is correct, if the network is open (no encryption, WEP/WPA/WPA2) then you can just "Join" the network and sniff the traffic.  However, you do not need to join the network to sniff the traffic.  WLANs use radio frequencies, all you have to do is match the freq (channel) and have a wireless card that you can put into monitor mode.

If the network is using encryption you can still sniff all the packets.  The only problem is that it will be encrypted.  However, if you manage to capture specific packets you can break the encryption (WEP) or get the key (WPA/2) and then decrypt all the data you captured while still not "Joined" to the network.

Like Terry said, Wireless is wireless, it's like broadcast television.  If you tune to the right frequency (channel) you pick up data.


Password guessing: Is it more effective to try many passwords against a few accounts or a few (very common) passwords against many accounts? I was watching a security vid on Irongeek the other day (I immediately lost track of which specific vid, unfortunately) where the creator gave some interesting advice about doing live password guessing against a remote machine during a pen test. The advice was this: using the "traditional" approach of picking one or a few user accounts and then hitting them with a sizable dictionary of common passwords is usually a poor way to go about things. As an alternative, the author suggests what is basically the opposite approach. Meaning: choose a very small database of the most common passwords and run it against a large list of users.  The argument being that you're more likely to be successful, in terms of breaching at least one account, if you try 100 extremely common passwords against 100 accounts than if you try 10,000 common passwords against one account.

My question: what are the advantages and disadvantages of using this approach in a password audit or pen test vs. the approach of attacking one/a few accounts in-depth? The most obvious disadvantage is, well, obvious: if you want or need to target a specific user's account this approach is probably off-the-table. On the other hand, it does seem plausible to me that if you're just looking for gaining entry into one or two accounts of any kind in an organization that has, say, at least a few hundred users this might well be a more effective tactic. And maybe, in some circumstances, it might also make dealing with login-attempt throttling/ lockout protections easier.

But my personal expertise in password hacking isn't very deep.  So, I'll ask those who know more than I:  What are other significant practical advantages & disadvantages of using this approach vs. hitting a few accounts with lots of passwords?  What are some other common circumstances where it does make sense to use one tactic or the other?

There are huge advantages to having access to any account on a system, even if you'd like access to a specific account. I will not detail methods to hide a system wide user base password attack here, however it's possible. Then, a direct attack against a specific account can be done. A random account on a system allows:

Access to any internal information like a user directory, phone numbers, email or snail mail addresses, etc.
If corporate, employee relationships (manager - direct reports), departments names, high level managers.
If corporate, internal servers (email, bug database, source code, employee facing financial systems, call centers, etc.).
If corporate, password may be useful for VPN login and subsequent network mapping.
Access to system or internal servers may allow code injection into the server (not possible without an account). For example, XSS attack or SQL injection attack. Some code injections may lay traps for users when logging in or accessing a system. Other code injections may break system security and provide access to backend databases.
Some poorly secured systems are subject to deep linking attacks (hacking url to skip over application security) and depend upon friendliness of user base to not hack URL. An outside attacker with access to an account may find these holes.
Surveillance of any specific accounts to attack (username, personal information useful for password guessing, phishing of managers, underlings, assistants).
Knowledge of internal systems, data and employees creates incredible potential for a wide range of phishing attacks on all employees including electronic, telephone and physical (vendors, contractors) and may allow granting of new credentials (user account) possibly with very high access privileges.

A single internal account on any system can prove extremely valuable in the hands of a knowledgable, creative and dedicated attacker.

If 99% of accounts have fantastic password security, and 1% lousy, attacking a handful of accounts would most likely miss the easily penetrated ones. Sweeping them all will more than likely catch something at which point attacker gets to try all of the above.


How does UNC path hardening and SMB signing work under the hood? With a lot of unpatched versions of Windows in an Active Directory domain, one can man-in-the-middle a client when it connects to the domain controller and inject a group policy that gives an attacker local administrator privileges (https://labs.mwrinfosecurity.com/blog/how-to-own-any-windows-network-with-group-policy-hijacking-attacks/). The solution is to use UNC path hardening for SYSVOL. What does this do exactly? How is it related to SMB signing? Presumably, at the end of the day it must be something similar to x509 certificates. If so, when are the public keys exchanged?

UNC Path Hardening comes from the JASBUG vulnerabilities (MS15-011 and MS15-014).

Microsoft suggests implementing workarounds to the SMB MITM issues easily found in the Responder.py or related tools and techniques (e.g., CORE Impacket, Potato, Tater, SmashedPotato, et al) which include but are not limited to SMB Signing. More information available via these resources:

"Extended Protection" primer and implementation guide to prevent MITM
https://digital-forensics.sans.org/blog/2012/09/18/protecting-privileged-domain-accounts-network-authentication-in-depth
http://www.snia.org/sites/default/orig/SDC2012/presentations/Revisions/DavidKruse-SMB_3_0_Because_3-2_v2_Revision.pdf

The basics: Implement protection against SMB MITM and Replay with always-on SMB signing, Extended Protection for Authentication (EPA), and forcing use of SMB 3 (or at least SMB 2.5 with proper RequireSecureNegotiate -- SMB 3 everywhere may require Win10 clients and Win Server 2012 R2 with domain and forest functional level of 2012 R2) while ensuring NBT, LLMNR, WPAD, and DNS don't create other MITM protocol scenarios.

After which, JASBUG can be patched after the UNC Hardened Path configuration is added. Note that the patch does not imply a fix, so the person who commented under the original question does not understand the JASBUG vulnerability (a common finding).


FTP over SSL vs HTTPS implemention Consider two implementations of SSL on a HTTP server and on an FTP server. With the same cipher suites used and the exact same protocols used.

Is one more secure than the other. I have heard that it is difficult to get FTP to downgrade protocols. So is the implementation of SSL onto FTP more secure than through FTP?

Is one more secure than the other. I have heard that it is difficult to get FTP to downgrade protocols. So is the implementation of SSL onto FTP more secure than through FTP?

FTP over SSL should have in theory the same security as HTTP over SSL. But in practice this is probably not the case:

HTTPS is most often used in Browsers. To deal with broken servers browsers implement SSL downgrading if the connection fails. Note that this behavior is not inherent to HTTPS, but to a specific implementation inside the browsers. HTTPS implementation outside the browsers usually don't to SSL downgrades and instead fail on the first error, as do SSL implementation in FTPS clients.
FTPS is not widely used. And if it is used then often with self-signed or otherwise broken certificates (like missing chain certificates, mismatch of hostname...). FTPS clients tend to either ignore certificate errors or let the user easily continue without proper validation. Some even do not check the certificate at all or do incomplete checks (like not checking the name in the certificate). In contrast browsers today often present warnings on certificate errors which are hard to bypass. Other applications using HTTPS instead often have the same problems as FTPS clients, but slowly they implement at proper checks which are enabled by default.
FTPS has several grades of security. The best mode is to encrypt control and data channel, but this can conflict with protocol helpers on middleboxes (like firewalls or NAT routers) which need to check or rewrite responses to PASV/EPSV or the PORT/EPRT commands, so that the necessary ports can be opened on the middlebox. Thus FTPS can downgrade the control connection from SSL to plain again (with CCC command) and from then on all traffic on the control connection is no longer encrypted. This opens the way for man-in-the-middle attacks which might even try to downgrade the data channels to plain text by returning an error code to the PROT P command which is used to setup an encrypted data channel.

In summary I think HTTPS is more secure in practice, even if browsers downgrade SSL protocols on errors.


how to import a private key in windows Say I have an X.509 cert and a private key that corresponds to it. I can import X.509 certs easily enough into Windows but what about private keys?

Is the only way I can do that by converting both the cert and the private key to a "Personal Information Exchange (PKCS #12)" file and importing that?

Maybe this question would be better on superuser.com?  Either way, thanks!

The answer to your question is Yes. You must convert the X.509 into a PFX and import it. There is no separate key store in Windows.

You can convert your certificate using OpenSSL with the following command:

openssl pkcs12 -export -out cert.pfx -inkey private.key -in cert.crt -certfile CACert.crt


CVV credit card change Is there a certain formula that the bank uses when changing the CVV (Card Verification Value), on a credit card. If I am trying to keep credit cards on file and they expire I know there is a form that where the CVV can be changed?

No, You can't change CVV at anytime. It is embedded within black strip which resides on back side of the card.

Each credit card has an expiration time, after which, you'll get a new credit card, with a different CVV altogether.


Sharing Derived Unique Key Per Transaction (DUKPT) Base Derivation Key (BDK) with a partner Assumptions:

We have devices out in the field injected with keys derived from our one and only BDK.
The devices encrypt data using the injected derived key.
All our devices connect to our server where the data is decrypted.
Our server connects to 2 different processors (A and B) for transaction processing.

Now lets say processor B says that they want the data to remain encrypted all the way through to them and hence asks us to share our precious BDK with them so that they can decrypt the data.  What is the recommended way for doing this?

I want to do it in such a fashion that if BDK is compromised at processor B, all of processor A’s devices remain safe. An obvious way would be to create two BDKs: BDK-A and BDK-B.  All of processor A’s devices will use BDK-A and all of processor B’s devices will use BDK-B.  But the disadvantage of doing so is that now at the time of key injection we will need to know which processor the device is for and inject keys accordingly.  That makes device preparation process more operationally expensive.

I want to know if there is a way to keep things operationally simple and yet minimize the impact of a compromise at processor B.

If B specifically wants the data encrypted end-to-end from the field device to them, then indeed you need devices injected under a BDK known to B -- either you generated and gave to B, or B generated itself and gave to you or your vendor(s)/injection facility(s) -- and preferably not used by or shared with anybody else.

You don't say what type(s) of devices and users/settings you are concerned with. I have seen (in the US) some retail/point-of-sale (magstripe "swipe" and pinpad, sometimes EMV) devices that can be injected with two device keys, under two different BDKs. But the ones I saw tended to be the higher end (thus more expensive), and you still have the problem of choosing which key to use for a given transaction/data-item, which usually means some other system that is interfacing with the human(s) involved, like a cash register/till, being modified to make this decision and command the device.

If B is only concerned about the data being encrypted all the time so it isn't vulnerable to attacks, they might well be satisified to treat your server as a single (unusually busy) device in their network -- i.e. they assign you an initial key (and corresponding initial KSN) under their BDK; you get each transaction encrypted by the device under a BDK-A key, decrypt it and immediately re-encrypt it under the BDK-B key, and send it up to B.

If you are using an HSM for your crypto, and for large volumes of payment-sensitive data you should, this is often provided as a single operation called "translate" -- that is, instead of "decrypt under key #3" then "encrypt under key #17", your software can request "translate from key #3 to key #17", and then the plaintext is never visible in your CPU/memory/swap, only within the dedicated and hardware-protected HSM.

Depending on your transaction volumes this could burn through the somewhat-less-than-2^21 values of TCTR pretty fast, so B may have to send you another "device" key (or maybe several) every month, or week or whatever, using some mechanism that is both secure and as automated as possible to avoid mistakes. You should definitely try to have each new key ready at least a week before you expect to need it, preferably more, in case volume spikes or some fault forces you to switch early. But if they're making money on the transactions you send them, and they presumably wouldn't accept your business otherwise, they should be able to manage.


What should a secure passphrase look like? We all know that passwords should not only be randomly generated, but also look random. The reason is that attackers can use patterns or existing words to be able to bruteforce the passwords faster, so a randomly generated password that (by pure chance) looks like wwwtroy31 is less secure than a randomly generated password like 2ug9wf4v. The question is: should the same reasoning apply to passphrases? How? What should a secure passphrase look like? What kind of passphrases should be discarded, even if we generate them completely randomly?

The concern is perfectly valid for short passwords like a PIN for a payment card. If you generate a random four digit PIN, you have a 0.01% chance of generating “1234”, a 0.05% chance of generating “flush“ in format n & (n + 1) & (n + 2) & (n + 3)*, a 0.07% chance of generating “reverse flush” (n & (n - 1) & (n - 2) & (n - 3)*), a 0.1 % chance of generating a PIN that has all digits the same and so on. Maybe those probabilities are low, but they are still non-negligible and when you sum all of them (and ideally add some other undesired patterns), the likelihood of having one increases.

Adding some rules for PIN generation is a bit tricky, however. If you are too eager to reduce the PIN space, then the attackers also have a smaller set of potential PINs to try.

The longer the password is, the less this is a real threat. For a 6 character password (^[a-zZ-Z0-9]{6}$, uniformly distributed), generating passwords like “123456” is rather unlikely (but still somewhat plausible). When you generate a password using 128 bits of entropy, the probability that you will happen to generate an obvious password that crackers would guess is almost zero.

The same applies for passphrases, except that entropy estimation is harder for passphrases than for random passwords.

* The “&” operator is string concatenation.


How is encryption broken The title describes pretty well what I want to ask, because I just can't wrap my head around it. I understand the basics of breaking encrypted data with the method of kind-of-bruteforcing where you encrypt sample data then compare it to the encryption you want to crack. However I don't understand how cracking a sophisticated encryption works.

I will give this code I posted in another question, with risk because it wasn't accepted very well, but just to illustrate the simplest example

function my_hash($data){
    // Generate random salt
    $salt = substr(md5(str_shuffle('0123456789abcdef')), 0, 5);

    // Mask salt within the hash
    $hash = substr(md5($data. $salt), 0, -5) . $salt;

    return $hash;
}

function my_check($data, $hash){

    $salt = substr($hash, -5);

    return substr(md5($data. $salt), 0, -5) . $salt === $hash;
}

$hash = my_hash('qwerty');

Can you explain to me, if you had a super-computer and billions of strings encrypted with that function, how could you find out the algorithm they were encrypted with?

Edit: The suggested question is not answering the one I asked, it is explaining how to guess the hashing function that was used, not how to crack it and find the algorithm behind it. I can easily say it is md5 when it's 32 bytes long and contains characters 0-9a-f but there's a difference between plain md5 and what I posted above.

Not encryption
This is not encryption. This is hashing. There is no way back.

So I think what you're really asking about is black box reverse engineering. Like so >>If I have a black box algorithm and throw many strings into it and observe the strings that come out, will I be able to copy the black box in a simple way?<<

And the answer is "No". There is no general way of doing this.
You could of course brute force it and just throw a huge amount of strings into it and then save the output somewhere. And then do a table lookup.

But for the 2^256 (32 bytes) many entries that table would not be storable on earth. Or in this universe.

Enemy already knows the algorithm
Now regarding encryption: You generally don't try to guess at an algorithm, instead you assume that the enemy knows the algorithm and you try to make him guess at the key.

This is a design principle known as Kerckhoffs's Principle. And it's generally thought to be a good thing.


In what cases should applications be prepared for brute force? Today I had an idea: I've been thinking that one can use brute force to get some data from a university from our country.

It turned out my thoughts were true: an attacker can use brute force to reveal sensitive information.

How strong should be the protection against brute force for an application, for instance this university website?

In my case, I'm thinking to notify the right people about this so they can address it the right way (even I think they won't care at all).

According to the laws of my country, getting and manipulating the information that one can get from this university is illegal.

I'm thinking of the following scenario: I will probably announce the people that take care of that website, and maybe they will say: attacking us is illegal anyways––should they still care about my report?

this is illegal anyways––should they still care about my report?

Very much so.

To give one of a by now long series of such examples, consider (one of) the Yahoo hack, for example the 1 billion account hack reported in late 2016 (see also Krebs's coverage).

To quickly cover why "this is illegal anyway" is not a legitimate response:

Yahoo had some sensitive data (in this case, user emails, passwords, and possibly more) stolen, yet Yahoo still has a duty to announce (and investigate) the hack
that duty extends to its financial reporting, as explained in the footer of one of their press releases about the impact to users:

  More information about potential risks and uncertainties of security breaches that could affect the Company’s business and financial results is included under the caption “Risk Factors” in the Company’s Quarterly Report on Form 10-Q for the quarter ended September 30, 2016, which is on file with the SEC and available on the SEC’s website at www.sec.gov.

depending on your country, the duty of reporting may also be tied to fines and other legal or financial consequences (Europe, for example).

All this tends to focus on Personally Identifiable Information (PII), but in the case of a university, the loss or theft of research (particularly when not protected by patents) could impact the financial status of the university.
Not to mention the fact that universities do also hold PII, and so a breach would need to be investigated to determine what kind of data may have leaked.

I am not a lawyer, but there are so many cases where, at the very least, investigation would be warranted (if not required to determine the legal consequences), that I think the report would (assuming it was felt to be reliable, and accurate) given attention.

If you provide bad (or even overly noisy) reporting, then it may be they will ignore your report. But I would be surprised if conclusive evidence of a breach would be ignored.


Who and how can update cable modem firmware? This might sound stupid question, but I need to know: can only my ISP update the firmware of my cable modem? Or can I do it? And if yes, should I?
I have vague memory of once updating something using my PC after AVAST gave false alert about network being compromised (it was later solved as their screw-up).

I can not remember what I updated, just tinkering in panic and updating something from PC I have no found again later.

So I need to know - is it possible to update modem firmware myself? And could I ruin something about modem from PC side?

It doesn't matter at all if you own the cable modem or not.  Providers have policies (for several good reasons) about how endpoints are managed and most of them (especially the big ones, Comcast, Cox, Charter/TWC/Spectrum, etc) require that in order to connect to their network, your cable modem must run their firmware.  Its not even a choice, during initial connection handshake the cable modem downloads the appropriate firmware (every time, no matter what) and runs it. Trying to update the firmware to some other version, if even successful, would only result in losing connectivity until you reboot the modem, at which time it will load again from the network.

Now, its important to not confuse the cable modem with the router/firewall gateway device, in most circumstances these are two different pieces (the modem is strictly responsible for providing IP/ethernet connectivity over the coax, nothing more) so a much different answer would apply if you ask the same question about your router/firewall device.


Finding ecc private key from plaintext and public key I am working on a message authentication scheme using libsodium and ed25519.  The messages range in size from 256bytes to 1k plus the 56byte signature.  With a potential of 90,000 to 350,000 signatures+plaintext per day, many of them will have limited changes and may be very similar (status notifications with an incrementing timestamp ex. 2015083020000126 All's Well).

How susceptible is ECC(specifically ed25519) to a known plaintext attack?  How often should I be changing a source's private key to prevent a potential attacker gathering enough messages and reverse engineering the private key?

A good first step would be to introduce something similar to a session key, and then using a block cipher to encrypt the actual payload.

Encryption would work like this:

Generate a random passphrase which should more or less be globally unique and should never be reused. If you need to edit the encrypted file and reencrypt, generate a new key.
Encrypt that generated passphrase using ED 25519, and store the output at the head of the file along with other metadata (ie: the IV for your block cipher, etc.).
Sign your encrypted passphrase using ED 25519, so you'll never decrypt something that wasn't generated by you. Store this next to the encrypted AES key in the previous step.
Using your random passphrase for your block cipher, encrypt the payload using something with authentication like AES in GCM mode, or AES in CBC mode with an HMAC.
At the end of the file, generate a signature of the encrypted ciphertext, proving that you, the holder of the private key, vouch for its integrity.

This gives you a lot of benefits. First, you're now using a standard block cipher for your payload, and AES (in the right modes of operation) isn't vulnerable to known plaintext attacks. Second, now that you're using a standard block cipher, encryption and decryption will be much faster operations in CPU time. Third, using a block cipher mode which has authentication gives you integrity, and by signing the ciphertext, you assert that not only has the message not been tampered with, it was you who created it.

Step 5 above may not be necessary, as your signature in step 3 should be good enough combined with an authenticated block cipher like AES in GCM mode or CBC with HMAC.

Decryption looks like this:

Decrypt your random passphrase using ED 25519 and check its signature. If everything looks good, proceed, otherwise fail.
Use your decrypted passphrase to decrypt the ciphertext using your block cipher. Your block cipher should be providing integrity support (GCM or CBC+HMAC) and should fail if anything was tweaked.
At the same time that your decrypting each block, pipe the original ciphertext through the ED 25519 signature verification method so you're not having to rescan the entire payload once you're done.
After you've finished decrypting the ciphertext, validate that the signature (generated in step 5 above) is valid.

This should provide a pretty robust encryption system.

Since I see now that you're mainly looking for message authentication, I've devised another solution which just does that.

Generating message authentication codes:

Generate a random key to use with your HMAC.
Encrypt and sign that key and stick it at the front of each message.
Run your HMAC over the entire plaintext.
Append output of the HMAC at the end.

Validating message authentication codes:

Decrypt and validate the HMAC key at the head of the message.
Generate an HMAC over the plaintext as above.
Compare your HMAC's output to the stored HMAC at the end of the message.

Provided that you use a good hash function for your HMAC (ie: SHA-256), this should be a pretty good solution. It effectively removes your concern of known-plaintext attacks for ED 25519 (not that they exist, necessarily), and will generally be a much faster solution in performance than doing signatures natively in ED 25519.


What can one do when encryption methods fail? I'm in search of an expert to answer my curiosity.  Suppose that methods like AES/DES, SSH, PGP, RSA, etc. can be cracked or fail somehow.  In other words, suppose that it's possible to determine one key for a given security method.  I mean to say, that somehow a hacker has enough power to compute a key.

Are there any methods of security that can effectively deal with compromised keys?  I'm attempting to consider a model where a potential hacker/hijacker has considerable computational power at their disposal.  What can be done to prevent a security breach, if anything?  Are there methods available that deal with this?

The model you are using can be described as: "the attacker loans God's own computer". His computing abilities are infinite.

Most of cryptography falls down in the face of such a foe. However, there are a select few algorithms which still have some strength in that situation; the branch of cryptography which deals with that is called information theoretic security. A classic example is One-Time Pad, which is a symmetric encryption system where the key is as long as the message, and used only once (hence "one-time"): security relies on the idea that even if the attacker can try all possible keys, he has no way to know whether he found the right one or not. A more usable information-theoretic algorithm is Shamir's secret sharing scheme.

Practical usefulness of such algorithms is, to say the least, questionable: an attacker who has unlimited power would also prove wrong two centuries of mathematicians, physicists and other scientists, including the foundation of every technological advance since the steam engine. At that point, you should have more pressing worries than what could happen to your keys. Also, why an entity with such god-like power would even bother attacking your system ?


Security of a laptop order What's the likelihood of a laptop being compromised when it comes directly from a trusted computer store or a large, known computer technology company? Would there be any liability if malware or rookit was discovered?

What checks / scans would you perform if you wanted to be as sure as possible that it hasn't been compromised?

For the average user in a western country who buys from an established vendor the risk is likely low. Vendors typically set up all systems the same way with a common image and thus any compromise would affect a larger user base and thus gets probably quickly noticed.

But if the government is interested in messing with you then the risk is much higher.  It is known that government agencies might divert shipments in order to manipulate the content. If there is such a targeted attack against you it is likely that you will not be able to figure it out by running some common scans or doing common checks since they would make sure that the attack is not that obvious.


How to use SSL approach at the application level The SSL approach of using public/private key (asymmetric) mechanisms to establish a symmetric working key for data encryption seems like it would be a good approach for end-to-end secure data transmission at the application level. Especially when one end is in an insecure (whitebox) environment such as a mobile phone.

Basically I could use the SSL protocol (How does SSL/TLS work?) to get a symmetric working key and encrypt my application data for end-to-end communication.
Clearly I would need to develop client and server side components to make this work.

Is this possible? How about some pointers to examples?

First off, an important notice:

DO NOT ATTEMPT TO WRITE YOUR OWN CRYPTO! This includes using known cryptographic routines in a way that isn't standard. if you intend to follow the standards, then you should use a library designed 8and maintained) for that specific standard.

That being said, every time you encrypt a file using a public certificate (using, for instance, PGP with public/private key pairs or AS2), you're doing what you're requesting.

The file is encrypted using a random key and a symmetrical cypher and that key is then encrypted using the public key of the recipient. Here is a picture (from wikipedia) that illustrate that process.

This is also valid for S/MIME, EFS, etc.


Can you sniff packets from a router using wireshark? If you have a NIC that supports promiscuous mode is this possible? To my knowledge, I read that a switch uses a broadcast domain to broadcast packets, but if a router does not use this, is it still possible to sniff packets on your LAN?

Packets designated for the router will not propagate through the LAN network, at least not from the WAN side. All packets from inside the network will be available to other device as well, when put into promiscuous mode. A switch, which acts on MAC addresses, not on broadcast domains (thats a hub) can cause trouble indeed.


Standard form of email signature A little bit of background: I want to sign my emails for my own safety. None of my intended recipients are users of digital signatures. If one day someone were to impersonate me, I can prove my own identity, and disprove the identity of my impersonator.
I intend to use GPG to produce signatures for my emails. Right now, I am facing a dilemma on how to attach these signatures. Whether to use 'clearsign', 'detached signature', or just plain old 'sign'.

I will elaborate on my thought process, and the pros and cons I came up with, of each form of signatures.
Clear Signature
Pros:

No external program required to read messages
Verification can be done easily

Cons:

Intrusive and ugly headers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

some message
-----BEGIN PGP SIGNATURE-----

some signature
-----END PGP SIGNATURE-----

Detached Signature
Pros:

No external program required to read messages
No intrusive and ugly headers

Cons:

To verify messages, the content must be copied and formatted exactly like how it was when used to produce the signature. Reference here.

Normal Sign
Pros:

No intrusive and ugly headers

Cons:

Require an external program to read messages
Or the alternative is, to duplicate the content of the message. One for readability, and another that was baked in the signature, as produced by GPG.
When using the alternative, produces longer emails.
When using the alternative, to verify a message, one will need to compare the produced output from the baked content in the signature, and the duplicated plain content in the email.

If I were to resort to use 'clearsign', when my recipient don't have a clue in the purpose of digital signatures, the ugly headers will make my emails look unprofessional. I want to ensure any digital signature I attach to be as least intrusive as possible.
I could simply remove the headers. However, the process of verifying signatures becomes no less different than 'detached signature', although less error prone.
If I were to use just the normal 'sign' and duplicate the content for plain reading, in some cases, this procedure defeats the whole point of digital signatures through hashing and getting the fingerprint of the message.
What should I do? What's the norm of attaching signatures to emails? Are there other alternatives that I have yet to consider?

PGP/MIME (RFC 4880 and RFC 3156) is (in my humble opinion) the least intrusive way to PGP-sign mail. It puts the signature into an attachment of type application/pgp-signature using the filename signature.asc, which some email clients will be able to verify and others will at least recognize that it's a cryptographic signature.

However, if you control your server, you could consider using something more broadly adopted: DKIM and DMARC.
DKIM (DomainKeys Identified Mail, RFC 6376) signs your message body as well as several headers (typically From, Date, To, and Subject). Keys are served via DNS and signature verification is decently universal as this (alongside DMARC) is a key defense against spoofing attacks like phishing and Business Email Compromise (BEC).
DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) sets a policy: what to do when an email fails to verify its DKIM signature (note, it also must fail SPF, but you can mandate DKIM by setting an SPF record of v=spf1 ?all to permit nothing). DMARC can instruct servers to quarantine or reject non-compliant mail. It also has reporting built in so you can observe what mail might be inappropriately blocked.
This ensures all mail sent by your server is cryptographically signed, that it's verified by nearly all recipients, and that you can instruct recipients to block or quarantine mail that isn't provably from you.


Are RFID shielding sleeves/wallets necessary for payment cards? I have seen advertised several times now products that claim to "protect" contactless payment cards (e.g. special sleeves, wallets).

What exactly do these products protect against?

Is it just protecting against inadvertently using the wrong payment card when standing near to a genuine payment terminal?
Or is it possible for an attacker to steal enough information via RFID to be able to clone a card or otherwise charge something back to it?

Do you see them as necessary?

I'd like to say up front that everyone else who has posted here is essentially correct. I thought I would post a different perspective, as I am a user of RFID shielding technology.

Every card in my wallet has a RFID chip in it. Credit cards, ATM cards, Transport card, Office key, Drivers License, heck even my coffee discount card. Also, my passport has RFID.

I purchased a shielded wallet from ID Stronghold, black leather with each card sleeve individually lined with some shielding material (presumably aluminium, though the manufacturer didn't specify). This is important as some wallets only shield the outside and not individual card slots, so they are potentially vulnerable if your wallet is open, or thick/full enough to leave an opening. I also have a passport bi-fold with card slots, made from stainless steel mesh (can't recall what brand that was though.) I can verify that the cards in my wallet are unable to be read by and of the scanners I have tested, however your mileage may vary - as this article discusses, the use and effectiveness of several brands and models may differ.

I have 3 concerns about RFID chips.

Credit card fraud as previously discussed, is the most obvious and very real threat, though not yet all that prevalent (I would suggest mainly because there are still easier ways to get Credit card data).
Accidental card charges. Although this seems implausible because RFID is supposedly limited to operate within a few inches of the reader, but this has been shown to be an invalid assumtion and an incident of this is discussed on this Security Now podcast (there is a transcription if you prefer, search for "contactless" and you'll go right to the relevant section).
Identity Theft. While this is largely theoretical at present, this is the most concerning case.

This technology is not new, and neither are the attack vectors. With the number of cards and identification documents carrying RFID continuing to grow, and the cost of a potential attack diminishing, we can only expect these types of incidents become increasingly frequent.

Ultimately, you need to decide what you believe your exposure is to this type of risk. While I agree that shielding may still currently be important only to the paranoid among us, I would argue that the cost is minimal. My wallet cost no more than a regular wallet, and (though I agree that the individual sleeves are probably less practical) having the shielding built in makes usage no less convenient.


How does knockd work? It's rather easy to configure knockd for ex.: on an Ubuntu server's (10.04) sshd:

========================================================================
0)
# install knockd on the SERVER side
apt-get install knockd

========================================================================
1)
#
vi /etc/default/knockd
START_KNOCKD=1

========================================================================
2)
# the default config file looks sexy
$ cat knockd.conf
[options]
    UseSyslog

[openSSH]
    sequence    = 7000,8000,9000
    seq_timeout = 5
    command     = /sbin/iptables -I INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
    tcpflags    = syn

[closeSSH]
    sequence    = 9000,8000,7000
    seq_timeout = 5
    command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
    tcpflags    = syn

========================================================================
3)
/etc/init.d/knockd
 * Usage: /etc/init.d/knockd {start|stop|restart|reload|force-reload}
/etc/init.d/knockd start
 * Starting Port-knock daemon knockd    [ OK ]
netstat -tulpn | grep -i knockd
ps -ef | grep -i knockd
root     25069     1  0 11:44 ?        00:00:00 /usr/sbin/knockd -d

========================================================================
4)
# install knock on the CLIENT side
apt-get install knockd

========================================================================
5)
# first disable the INPUT for port 22
iptables -I INPUT -p tcp --dport 22 -j DROP

# save your firewall rules if needed to be permanent
service iptables save

========================================================================
6)
# try to connect without knocking:
telnet 1.2.3.4 22

# knock on the SERVER from the CLIENT to open port for 22
knock -v 1.2.3.4 7000 8000 9000

# try to connect after knocking:
telnet 1.2.3.4 22
========================================================================

It works, great..

QUESTION: But. If knocking means that we have to send packets to given ports, then shouldn't there be an "OPEN PORT" waiting for the knocking? How does it works?
Does knockd gives more security? (I mean that SSHD is well audited, and I don't know about knockd.. )

ssh on port 22 is a well known port.  If you leave port 22 open with ssh running on the internet and check your logs; you may see a couple thousand attempted entries a day (trying a variety of usernames).

knockd does not require a port being open or bound to a process while sshd requires the port being both open and bound to a process.  knockd requires your router to forward packets sent to the specific ports to your server, but a software firewall can either drop (ignore; no response) or reject (send back icmp-port-unreachable or similar) the packets.  Since knockd is just listening to your ethernet interface (and not examining the content of the packets in anything but the most superficial ways), it can detect that packets were sent to these closed ports without doing any additional processing on the packets that then get dropped by the software firewall (e.g., iptables).

So if you define a custom knock with say three ports randomly chosen; you've just added 48 bits of entropy (each port is between 0 and 216-1) before anyone can access your server.  Granted; don't relax your security on sshd; as anyone sniffing traffic can observe your secret port knocking pattern and replay it; at which point they can start trying to attack sshd.


Getting rid of trojans on Windows XP - the basic toolkit I haven't had to clean up PCs in a while but it's this time of the year when you go visit relatives and they ask you about this and that, malware and trojans and other delicious things that pop up in computers.

What's the standard set of tools you use to get rid of trojans? Is there a good website reference I can turn to? Googling leads to a lot of commercial websites.

I'm not asking for opinions but rather for the set of well accepted tools to clean up PCs.

Cheers,
David.

In my view you cannot completely clean up virus from Win XP without re install.

If you are not interested in that, I suggest you to install a good antivirus and initiate a boot-time scan.It will surely reduce the threat up to a limit.

Best Antivirus Software Ratings


Using FileVault on a Mac with existing data I have recently got a Mac which I have started using already without any encryption while looking for the best solution. I have come to the conclusion that using Mac's own file encryption technology FileVault will be meet my requirements and easiest to use.

What I would like to know is by encrypting the drive now, will existing files that I have on the SSD be recoverable as its been stored without encryption previously.

It depends on how serious your potential adversary is. If they're just using normal data recovery tools, they won't be able to get at anything without breaking the encryption first. But because of the way SSDs write data, if they're really serious about it, an adversary could disassemble the SSD, bypass its flash translation layer, and get access to blocks that've been "overwritten" but not physically reused yet.

SSDs actually have more capacity than they expose to the outside world (i.e. the computer), and when you "overwrite" a block, it doesn't actually overwrite the physical storage, it puts the new data in a different physical location, updates its translation table so the outside world sees the new contents instead of the old, and adds the old physical block to a reserve that'll later get reused for some other logical block. See this AnandTech review for way more details (warning: the relevant bits are scattered through a very long review).

Because of this (especially the fact that the flash controller hides what it's doing), making sure that all old data is overwritten is really really hard. Researchers at the Non-Volatile Systems Lab at UCSD have tested various ways of sanitizing SSDs by "erasing" the drive, then disassembling it to bypass the controller, and checking for remnant data (summary, full paper). They're considering the problem of erasure without replacing the data with an encrypted version, but the basic problem is the same either way. And their results weren't pretty:

  Our results lead to three conclusions:
  First, built-in commands [ATA secure erase] are effective, but manufacturers
  sometimes implement them incorrectly. Second,
  overwriting the entire visible address space of an SSD
  twice is usually, but not always, sufficient to sanitize the
  drive. Third, none of the existing hard drive-oriented
  techniques for individual file sanitization are effective on
  SSDs.

If you're worried about someone going to that much trouble to get your data, there are a couple of options that might work:

Convert to FileVault, then create & delete a bunch of large files to force enough block reuse to fully drain all blocks containing old data out of the reserve. How much will this take? According to the NVSL's results, creating & deleting files equal to the capacity of the SSD should do it (the conversion to FileVault essentially overwrites 1x the drive capacity, so you need to bump this up to 2x).
Copy all of the data off (preferably to an encrypted drive, so we don't expand the problem), run an ATA secure erase on the SSD (essentially, tell its controller to overwrite all physical blocks), hope that the controller actually does this right (not all will), then encrypt and restore.

And one option that will work:

Replace the SSD, encrypt the replacement before copying data from your old SSD, then physically destroy the old SSD. And BTW I want complete physical destruction, not just breaking the controller board and leaving the storage chips intact; see this analysis from the NVSL people on how fine you need to grind it.

I realize none of these are particularly good options, but it's too late for the best option of all:

Never ever store sensitive data on an SSD in unencrypted form.


Is signature an universal biometric trait? Where "universal" stands for "The trait must be owned by any person (except for rare exceptions ...)"?

(Notice: this is a question related to biometric systems, hopefully this is the right stackexchange site).

This is absolutely not my area, but I think the answer is no.

It isn't universal because not everyone can write (illiteracy, blindness, missing limbs, spring to mind) - see https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/118600/applicants-unable-to-write.pdf .

I would assume that if there exist provisions for delivering a passport without the need for a signature (thumbprints are one option, but assume that the person has a thumb - the absence of one might be part of the reason the same person cannot write), then it isn't universal.

I also suspect that inability to write might in fact be common enough it can't be considered an edge case - the worldwide literacy rate is apparently around 86% (https://en.wikipedia.org/wiki/List_of_countries_by_literacy_rate).


Using the index of characters in a security question I'm seeing many sites offering one or two "security questions" that have to be answered by choosing characters at specific indexes, in addition to username + password. For example:

"What is your mother's maiden name?"
1:[]  5:[]  8:[]

And you're meant to enter the first, fifth and eighth characters of the answer you've set up.

Now ignoring the fact that it's not really adding another factor (it's still what you know, not what you have etc.), and social engineering, etc., is there a way to securely store the information server side in a hashed format, and still provide the functionality?

In other words, say a security answer is "smith". I want to be able to store that in some hashed format, so that when the user enters their 1st, 3rd and 4rth character, I'll be able to check whether that matches. I don't want to store "smith" encrypted - I want to be able to take the hashed value of "smith" and the user's input and say "yup, it's fine" or "nope, you got it wrong". Is this possible? What algorithm(s) work well for this?

I ask, because my bank's mobile app has started using this for log in, and I can't seem to figure out how this can be achieved without being able to recover "smith" from the stored value.

In all generality, no, you cannot use such a scheme with a storage based on hashing and still expect the same kind of security as with full-password hashing as it is normally practised.

Here is the demonstration: the point of storing the hashed password, and not the plaintext password, is that you just assume that attackers may obtain a (possibly read-only) glimpse of the server's contents (e.g. with a stolen backup tape). With that copy, the attacker can emulate the server behaviour on his own machines.

In particular, the attacker can:

Start his emulation of the server.
Begin an authentication procedure with that emulated server. The server asks for, say, the 1st, 5th and 8th letters of the user's password.
The attacker snapshots the whole emulated server state at that point.
For every possible combination of three letters, the attacker restart the emulated server at the snapshot point, enter the three letters, and see if the emulated server is happy or not.
Once the attacker has found the right combination of three letters (there are only 26×26×26 = 17576 combinations of three letters, which is really few for an automated attacker who can do things by the million -- remember that all of this happens on the emulated server, on the attacker's own machines), he can start over at step 1, to guess other letters. After a few iterations, the attacker has the complete user's password, and can confidently log onto the real server.

In practice, the attacker does not need to really set up a complete virtual machine with snapshots; he can just concentrate on the few kilobytes of code that handle the authentication process. But basing the description on snapshots and server emulation shows that this kind of attack is generic, and there is nothing that can be done to protect against it as long as the attack model applies.

To again achieve security, then, the model must be made not to apply. In the discussion above, I assume that the attacker can get a copy of the server state. Thus, to prevent that attack, we must make it so that there is at least part of the server state that the attacker cannot plunder. In that case, just store a symmetric key K in that attacker-free part of the server, and use symmetric encryption for storing the passwords.

I expect most sites that asks for letter combinations within the user's password to use such reversible encryption. This can be considered as "safe" if the key K is indeed kept out of reach of attackers, which is hard unless you do it seriously (and expensively).

Still in all generality, asking for three letters means that you grant entry to random attackers with probability 1/17576, which is, in my opinion, a bit too high for comfort, considering that we are talking about a publicly reachable server. The whole concept of asking only for some letters is meant to be "more secure" but in fact it is more about sprinkling some obnoxious ritual elements so that you may feel more secure, possibly at the expense of actual security.


Is it possible to send a message and 100% obfuscate the origin of the sender in a p2p networked message board? I am thinking of an app that could allow people to share text so they can post grievances about a totalitarian government in a p2p network. It has to be p2p because a website can be blocked. This would be for locals to post about their mayor or the neighborhood cop. Let's not worry about social engineering, let's only worry about the technical side of it.

Is it possible to 100% obfuscate the origin of the message creator? I know that TOR is not 100% secure. I imagine something like if someone were to send a message from a burner phone or the message is encrypted and split into multiple places then reassembled later. Meanwhile, the reader's origin doesn't need to be 100% obfuscated since they can't arrest millions of people just for reading it. They only want to catch the message creator.

The obfuscation of the original sender is paramount because without that, people would be too afraid to post anything. Right now there are always dissenters, but they are few and they post to places like facebook. Then eventually they get arrested.

Also the service should only allow text because there is potential for governments to introduce CP into it to destroy the legitimacy of it.

Do any of you know of an app like that? Would any of you be interested in modifying a TOR client to allow easy access to location based message boards?

You can use something like that:

User connects to server, authenticates the server, and negotiate a set of keys
If the user have something to post, he encrypts the message with the key, padding it to fit an arbitrary fixed buffer, and larger messages are broken into pieces and sent later
If the user don't have anything to post, client generates cryptographically secure random garbage for the same buffer size
From time to time (10 sec, 1 min, 30 min) client will send the message
Server decrypts the data with its private key, determines if it's a complete message, part of a large message, or garbage, and reacts according to the message type

In this case, as long as you protect the server, nobody can know if the user is reading messages or posting messages, as the client keeps sending the same kind of data periodically: same interval, same size, same entropy.

Data traffic analysis will fail, as the client will send the same data size with the same interval no matter if the user is posting or not. Posting messages longer than the buffer will take more time, but it will be worth if the main use of the system is anonymity.


Are there any security advantages to the "TrueCrypt-Paradigm"? TrueCrypt and its successors use a file format that has the special property, that it looks completely random, there's only a salt (which is random) and the cipher text (which looks random). I like to call this the "TrueCrypt-Paradigm".

Is there any advantage to using the TrueCrypt-Paradigm as opposed to introducing non-random data such as key-derivation parameters?

Bonus points if you can find a situation where the (theoretical) advantage actually helps / saves / whatevers you.

To be explicit: I do not ask about the disadvantages which include, but are not limited to:

Inflexible password based key derivation
Inflexible cipher selection

Yes, there is a very real advantage. Take this hypothetical, but very likely scenario. You are storing something Very Bad(tm) that you absolutely do not want the police to find. Your opsec is pretty good, but you make a single mistake online, and the cops are on their way. It's 4 AM in the morning, and they burst in with a fresh warrant for a no-knock raid. You stand by helpless as they take every single device in your house, all of your dozen flash drives and SD cards, your hard drives, laptops, etc.

Days later, they confront you again, asking you if any of your flash drives are encrypted with something called "TrueCrypt". They know you are tech savvy enough to use it, but they also know you are tech savvy enough to wipe your flash drives. They have no idea whether or not you encrypted it, or you simply wiped it. They can't force the key out of you, they can't lock you up for refusing to give them the key, and most importantly, they can't spend a long time trying to crack all of your dozen either-wiped-or-encrypted devices because spending too much time on a single case gets investigators in a lot of trouble.

Because you used TrueCrypt, the devices which you simply wiped blend in perfectly with the devices you have encrypted. You're let free after the cops are reprimanded by an angry judge who regrets signing the warrant in the first place.

This example is especially potent in countries with mandatory key disclosure laws, where if they have evidence that you are hiding encryption, they can lock you up. If you can claim that you simply wiped your hard drive and it's all random data (which is especially plausible if you have a spare CD with DBAN burnt on it lying around), then no matter how much they want you, they'll have a very hard time getting you locked up. But even in countries without such laws, it's still an extremely good idea to prevent your adversary from knowing where to focus their efforts, or even knowing that they have found what they are looking for.

Note that this "TrueCrypt-Paradigm" is much more effective on entire disks. It is significantly less effective when used as individual volumes, because it's not that easy to explain away a large, random file sitting on your hard drive, especially if TrueCrypt is installed on that system. Not as easy as it is to explain away a hard drive with random data, where even if TrueCrypt is installed on some computer in your house, it still isn't even close to enough evidence to point to that specific hard drive being encrypted rather than just wiped.


Is there any security benefit to not using cookies? I was reading how the infamous TorMail had a legacy mode that allowed their email service to be used without cookies.  The article implied they did this for privacy concerns for end users.  From what I understand, it's not possible to store sessions without cookies.  So I have to ask:

How do people not use cookies, do they use PHP sessions or something similar?
If we don't need cookies, why use them?
What is the security/privacy benefit of avoiding them?

Why cookies, and what are the alternatives?

HTTP is stateless. A webpage that remembers you (so you don't have to reenter your password every time you visit a new page) is stateful. To bridge the gap between the stateless protocol and the stateful applicaiton you need some kind of session identifier that is included in every request.

The standard way to do this is with a cookie. But you could put it anywhere in the HTTP request. Some examples:

A common practice back in the day was to put the session identifier in the URL, but this meant it ended up in all sorts of logs and leaked via the referer header. Not so good.
A single page app could just store the identifier (e.g. an authentication token) in a JavaScript variable on the client, and then send it in a custom header with every request. It would be like a cookie that only lives for one page load. (As Marko Vodopija points out, the security would be somewhat weaker here, since the identifier could not be protected by http-only like a cookie can.)

You can think of these as different ways of "simulating" a limited version of a cookie.

PHP uses cookies for its sessions, by the way.

Why do some people dislike cookies?

There is nothing inherently insecure about cookies, and using them is not less secure than any of the more contrieved alternative methods. On the contrary, as we have seen, some replacements are worse.

The reason some hate cookies is the same reason they are so useful - they make the web stateful. This means that they can be used to track you, with all the privacy implications that comes with. So some might want to disable cookies completely.

That is probably the reason why a privacy focused site would offer a cookie free alternative. It doesn't make the site itself any safer, but it can service users who have cookies turned off for privacy reasons.


How do banking software systems securely store account information in database? Banking systems store account information in databases such as Oracle and databases are maintained and administered by DB administrators. The account information is stored in a table and a column of that table may contain balances. So it sounds like a DB admin can change balance of an account and for example he can put a few zeros in front of current balance.

How does banking software prevent such changes?

How do they store monetary value in databases?

Is there any standard for that?

They prevent it by using access controls to restrict access to who can change data fields and by implementing auditing to monitor authorized changes.  As you might expect, a database holding banking information is typically fairly restrictive on who can make changes.  They also have transaction logs that may be used to validate account balance changes, where if an account balance change is noticed without a corresponding transfer from another source it is flagged for review.  This as well as the user audit logs maintained work as a means to discourage unauthorized changes as well as identify the source of a change if one was made.

Different countries have different standards, but in the United States of America we have federal and state regulations that subject financial institutions to both internal and external audits of their practices.  Maintaining proper technical and process controls over account management are part of the things these audits investigate.

All of these measures don't make insider fraud impossible, but it makes it much more difficult and likely to be detected.


SSH Brute Force Dictionaries Request for logs please.

So, I had an interesting question posed to me around geographical trends in SSH brute force attempts. The question being "has anybody ever looked into the prevalent SSH username lists by country?"

I happen to think that this would be an interesting little project and would like to do some research but to make this a statistically useful exercise will require access to more logs than I have.

So, would any of you be willing to share SSH logs for failed passwords /invalid users?

The logs would need to contain the source IP and enough verbose detail for me to see either a failed password attempt or an invalid user name used.

Like Project Honeypot?

These are spam harvesters, but the idea is the same.  By country


Tracing the email sent from SMTP How can someone be traced over email/SMTP, if they connect via telnet to SMTP and send and email.

I know that email can be spoofed with this method, but how secure it really is? Can I see who was loged via telnet or who send an email via telnet?

I saw this method for "spoofing" emails here.

I assume you mean by 'tracing' that one can determine your location. Your location can be determined by the network address.

There are several ways to determine your network address whilst connecting to an smtp server via telnet:

The owner of the smtp server can log all activity, including your network address.
Intermediate nodes between you and the smtp server can log your network address.
On the receiver side, the e-mail you spoofed will contain your network address in the Received header.


Are different top level domains somehow different security wise? If so why is the difference?
I've tried to google it but nothing relevant was found.

In the general case probably not, although I'd imagine that the authorities running each TLD will have varying levels of technical and operational security, so your domain may be safer with some than others.

One specific case to note however is the prospective .secure TLD whose goal is specifically to provide a secure environment both in terms of their security and the security of sites within the .secure TLD


The benifits of Full NAC solution VS simple radius server In case we want to enable dot1x authentication on the wired network without using host checker,do we still need NAC solution or just simple AAA server to authenticate the host and dynamic VLAN assignment? Any added value for the NAC solution in this case?

The solution of NAC basic use two features. Posture and Profilling.

In the case of not using Host Checker(Agent) you are "losing" posture features - check patchs, av, registry and otheres stuff.

Using only a radius server you are "losing" the profilling of the endpoint.
This may have huge impact - that depends of the size of your network.

If its a small network, withou many kinds of endpoints - Notebooks, Cellphones, cams etc. I should be ok.

But if you have a medium large network it s going to be difficult to manage and control all kinds of endpoints. That exactily what profilling do for you.