Are there security reasons for prohibiting universal mac address modification? Background
In a standard 48-bit MAC address, the 7th (most significant) bit specifies whether it is a universally-administered address (UAA) or a locally-administered address (LAA).
If it is 0, then the MAC address is a UAA and the first 24-bits are the organizationally-unique identifier (OUI) of the manufacturer of the network interface card (NIC).
If it is 1, then the MAC address is just an LAA.
Question
Many drivers and NIC's often allow users to modify the MAC address of their device.
But, it seems Windows does not allow modifying mac addresses to universal ones (i.e., UAA's): https://superuser.com/questions/1265544/
What is the reason for this restriction? Are there security implications if this was not the case? Or, perhaps, is this merely just to prevent someone from spoofing a device as some legitimate company's network communications product? (to their ISP)

It is difficult to answer this question, because we don't have any insights on the way of thought of those at MicroSoft.
However, as you said, there are two types of MAC's: a universally-administered address (UAA) and a locally-administered address (LAA).
UAAs get the MAC-ID from the vendor; it contains the vendor's OUI.  Although you can, you should never use these yourself, unless you are a vendor. They are (more or less) guaranteed to be unique. You should never get a second device with the same MAC; no collisions.
LAAs are meant to be locally administered. If you get a collision, it's your problem.
So, for a normal end user, or  even a company, if you use your MACs, you would only use LAAs, by fear of collisions. Why should you need to change it to an UAA then? Windows probably would conclude that this is an error that must be prevented.
For many of these actions, there is a "are you sure"-dialog. However, MicroSoft probably cannot see a legitimate case where such a change is needed, so you are probably hacking.
But then again, unless someone who made the decision at MS answers, we'l never know.


Is there a possability to inject XSS into the jQuery attr function? I was wondering if this function would be vulnerable to XSS.

var url = "google.com";

if (url.indexOf("http") != 0) {
    url = "http://" + url;
}

$("<a/>").attr("href", url);

The 'url' is user input, and the <a/> would be placed on some webpage.

I couldn't find a way to execute javascript code on this function. But before I implement this, it would be nice somebody can take a look.

What jQuery actually does when you use attr(name, value) is to call setAttribute(name, value) on the relevant DOM elements. Not at home in the jQuery source, but I think this is the relevant part. This means that you can not escape out of the attribute context. So it is as safe as vanilla JS is.

What you need to look out for is the following:

Don't let the users control the attribute name - that opens up the door to changing it to something malicious such as onclick. Unless you do whitelisting, only let the user control the value.
Some HTML attributes are inherently dangerous. This includes href, since you can do something like javascript:alert("XSS");. Since you make sure the value will always start with http you should be fine, though. Other examples of dangerous attributes are style and JS event handlers.


A security concern I dicovered with simcard devices Well, it all started when I wanted to take the sim card out of my tablet and I was about to shut it down so that I could take the simcard out.
But then a thought raced through my mind, "What if I take out the simcard before I turn off the tablet and go to google and see whether I can still search for something?"

So I quickly took out the simcard and I typed a word in the browser I have never searched for before(I checked my history to confirm) and....... It loaded and displayed a webpage!  I  clicked on a website very quickly and it also began to load it was almost through but before it fully opened the tablet quickly turned itself off.

This proves a theory I once had:Sim cards are identified on their individual operator networks using the IMSI.  Mobile network operators connect mobile phone calls and communicate with their market SIM cards using their IMSIs using a certain format.(Actually that's the factual part not the theory part I was talking about)

(Now the theory part) That IMSI format that is stored in the simcard is accessed by the phone as it transmits that data using a radio link to a cellular network .Now as the device sends this data it stores the same data along with the encryption key of the simcard on its RAM. Since the device here is the middle guy he can store the information being transferred without the simcard or the carrier. Meaning when the device obtains the encryption key it stores it on its RAM as it passes it to the mobile operator requesting access and authentication and once the mobile is granted access to the operator's network it stores the encryption key because the encryption key is used to encrypt all further communications between the device and the network hence having no need for the simcard anymore. Which explains why when I removed my simcard from the device I was able to surf the net. But as a security procedure(one that worked terribly slow allowing me to surf the net for a brief period of time) the tablet turned itself off, and since it was stored in the RAM once it turns off the information is lost. But isn't this a great security concern?

What if someone made a program that overrides the devices settings allowing the stored information to be continually used without having the simcard?

Basically what I'm asking is that,  isn't it a great security concern for devices to function this way?

As you found out, a SIM card is only required for initializing a connection to the mobile carrier and is not required anymore until the device loses the connection and needs to reconnect (which happens very frequently with mobile devices when you move them around). Your device might power down when the SIM card is removed, but there is no good reason why it must do that.

But cloning a SIM card is not as easy as you think. Every SIM card stores an unique Authentication Key which is only known to the network carrier. This key can not be read through normal means. During the connection process, the carrier sends a random number to the device. The SIM card then uses a cryptographic function which takes that random number and the authentication key as inputs and outputs a new number based on these. This function happens inside the SIM card, not on the device, so the device never processes the authentication key. That number is then sent to the network carrier. The same happens on the carriers side, and when the numbers don't match the connection attempt is aborted.

The calculation is (relatively) cryptographically secure, so it is not (easily) possible to reverse-engineer the authentication from observing which random number gets which response from the SIM card. It has some vulnerabilities, though.


Major differences between Kali and SecurityOnion Curious about the major differences between Kali Linux and SecurityOnion. Do you think it would be easy or useful to replicate what has been done with SecurityOnion on Kali? Why is there such a dichotomy between security breakers and security defenders... and is this divergence visible through these two primary (and heavily used) distributions? Ultimately, should there be a unified "infosec linux distro", are there already better alternatives to the two, and what is the future of guest VMs, booting from USB/SD/microSD/DVD/PXE, and integration with modern platforms (e.g., ARM-based, Android, SteamOS, ChromeOS, iOS, et al)?

Similarly, what are the major distros for IT/Ops-based infrastructure Linuxes? Ran across Zentyal before, but are there others (also see my last question below on virtual infrastructures), can they (or should they) be replicated on Kali/SecurityOnion, and what's the future of these distros as well?

Lastly, what about other distros that have critical importance to the infosec community, but that aren't "production-ready" because they are meant to be used only in labs -- e.g., Metasploitable, OWASPBWA, SamuraiSTFU, etc? Should this functionality be merged into a single package, such as an easily-installable OpenStack bundle? What is the future of Xen, XenServer, KVM, and ESXi in the face of OpenStack? Rackspace is mostly OpenStack, Microsoft mostly Azure-specific kernel (Server 2012), Amazon AWS-specific Xen kernel, VMware obviously ESXi/vCloud, and others are doing a mix of KVM (for Linux guests) and XenServer (for Windows guests) -- in light of these options, what is a good model for virtual infrastructures?

Your question spreads out into broader IT operations and virtualisation, which is not really within the scope of this site (you might want to ask those questions at Serverfault).

As for the Kali/Security Onion questions.  Kali is primarily an offensive security distribution for Penetration Testing and research and Security Onion is a defensive distribution for Network Security Monitoring.

There is little value in integrating the two for most users, as network defenders and attackers are almost mutually exclusive.  The main reason for this is that it is generally inappropriate for someone who built a system and designed its security controls to attempt to break it, they do not have "fresh eyes" to see flaws.  In the same vein, a penetration tester should be providing an independent assessment of the security of a system, if they perform security configuration or network defence on that system, that independence is suspect.

I wouldn't consider any of the distros you have listed as "critical to the infosec community".  Useful for training purposes, yes, but not critical.  That includes Kali, I don't know that many pen testers who run Kali as their main pen testing platform.  Most I know prefer to roll their own and install the tools they want.


How easily will the vBulleting data from vBulletin and Foxit be cracked? What data is at risk? How was it encryted? vBulletin Solutions and Foxit Software were breached.  The culprit (ColdZer0 or Coldroot) claims to have data from 479,895 vBulletin Service and Foxit Software accounts that include identifiers, security questions and answers, and password salts and hashes.

What data was actually exposed?
How were the answers and passwords encrypted?
How easy will it be to obtain the original values?

Note, a couple of years ago another vBulletin based site, MacRumors Forum, was breached.  Over half of the ~860,000 salts were reported to be just 3 bits long.  These were apparently older accounts that had not had a recent password change.

I don't have a copy of vBulletin myself to inspect, but multiple sources claim that their hashing scheme is:

  md5(md5(password)+salt)

This is unfortunate seeing as md5 has some documented weaknesses, and is also a "fast" hash. Hashing processes used for passwords should be slow to make brute force attacks slow (and hopefully practically impossible).

The good(ish) news is:

a. They were hashed and not stored in plain text

b. They are salted so a plain rainbow table attack probably won't work

The main threats are brute force attacks (especially dictionary based ones).

Hashcat has been benchmarked to 8,581,000,000 md5 hashes/second on basically a regular gaming PC. Assuming that the salts were exposed in the dump, an a-z password and 2 x md5 operations are required per combination then it would take about 48 seconds to brute force an 8 character password or 9 hours for 10 characters. Dedicated cracking PCs are considerably faster, and a dictionary based attack would be much much faster again.

Unless you have a very long password and you're certain it's not going to be in a dictionary, I'd consider your password compromised. In practice, I'd consider your password compromised regardless.


Using last four digits of Social Security number as password I attended a small community college and our network/user login to campus computers were our student ID as the username, and the last 4 digits of our SSN as the password. I thought nothing of it while I attended, but thinking back it seems unusual. Let me be clear about a few points.

All login verbiage specifically stated this information. So it was well know and not just limited to my login
You could not change your username or password for any reason
You could not login to their system outside campus

Perhaps I'm overreacting, but it doesn't seem like a good practice. Not only is the password short and limited to digits, but it's a partial SSN. Anyone else ever encounter this? Is there  a security risk?

The risk is that anyone who guesses your password can now also find your full SSN.

The first three digits of your SSN are based on where you were born (public information), while the next two are based on when you were born (also public information).  This leaves only the final four digits as secret information.

In normal usage, this isn't a major problem: an employer or bank isn't going to let you hand in thousands of fake Social Security cards until you come up with one where the name and number match.  But with the system you describe, an attacker can sit in front of a terminal, patiently entering numbers until they succeed.


Tracking IP address to prevent abuse without logging user metadata I am trying to balance good security practices against excessive logging of user metadata / Personally Identifiable Information.

I am constructing a web app that allows for secure messaging. In part of my system design, I am trying to minimize leaking of user metadata.

Part of my system design includes a module that tracks IP addresses to prevent abuse, such as Denial-of-Service or account cracking. I only keep the log of IP addresses around as long as needed. A straightforward approach would be to log the IP address and a timestamp in a logfile, and delete entries after a period of time. To head off any distractions, the intent is to ban abusive IP addresses for a set amount of time (i.e., linear offset), not permanently.

The threat model is that the logs could be used to determine who was using the system and when. I want the users of this system to have confidence that even if a server is compromised, that the logs are not designed in such a way that a third party could infer who used the system, and when, to talk to whom.

My first thought was that storing information in a form that can be verified later, yet not stored in plaintext, is similar to how one securely stores system passwords using a key derivation function (i.e., applying a hash to a passphrase and a salt for a large number of iterations). Thus, the same way that a user password can be verified against its KDF-based hash, an IP can be checked against its KDF-based hash in the log file to see if the same IP address has been logged before.

What are the strengths and weaknesses of this approach? Are there superior methods for storing user metadata / PII not in plaintext, in a format that a web app can verify?

Updated to clarify web app purpose, and the threat model.

Lets say you need to view the IPs over a 30-minute period to decide on abuse. Here is a scheme to keep the IPs no longer than one hour.

Every 30 minutes, generate a memory-only random string, RS.

For any time period, keep the current and previous RS: rs_c, rs_p.

For every IP, compute the current hmac using the current random string:

IP_c = HMAC(rs_c, IP)

Store the IP in a table:

IP_c, last-update

Compute the ip count over the last hour.

func get_ip_count(ip):
  IP_p = HMAC(rs_p, IP)
  IP_c = HMAC(rs_c, IP)
  count = [select count(*) from ipHistory where IP in (IP_p, IP_c) and last-update < [30-minutes-ago]]

As long as you can protect the RS, you'll not recover the IPs for more than your sliding window.

Clean the table based on last-update/age.

delete from ipHistory where last-update < [30-minutes-ago]


DNS IP address auto reset I have a unofficial Windows and i noticed that my internet connection gets reset.
By taking a closer look at it, i found that the DNS server address is set to an IP in China.
Any reason why this wouldn't be the sign of some backdoor ?

is set to an IP in China. Any reason why this wouldn't be the sign of some backdoor ?

If you are located in China then this would be probably fine.
If you are located elsewhere then it might be a backdoor or some malware like DNSChanger.


How long to wait before publishing a web vulnerability? I recently learned about wpscan and the WordPress security, so I decided to try it with a blog from my company. As a result I got several serious vulnerabilities that must be fixed. I notified several responsible two weeks ago and offered my help to fix it but nobody has done anything, not even have been interested a little. I would like to write an entry in my blog, summarizing what methods I used, the results I got ...

How long should I wait before publishing them?

If the company you are publishing a vulnerability for is your employer, it's never a good idea to publish the vulnerability. You may be a whistleblower, but you will likely lose your job for neglecting your responsibilities.

Publishing responsible disclosure applies mainly to external party who neither has a duty to the company and whose livelihood is not dependant on the company. The main reason for responsible disclosure is because it is in the public's interest to know about the issue, as well as for taking credit for the discovery which can allow you to build a reputation/resume. However, running a vulnerability scanning tool like wpscan is not really considered an original research, there isn't really much credit to gain here.

As an employee of the company though, you really should fight this from the inside. You are part of the company and you are in a much better position than an external party to push for the resolution of the vulnerability.

  How long should I wait before publishing them?

You should only publish the issue if you are ready to leave the company if the issue isn't resolved. Alternatively, if you judge that it is in the public's best interest to know about the issue, then you may want to go the whistleblower's route and publish it anyway if you think losing your job is a good enough cost for the greater good of public interest.

Although, do note that not all security vulnerabilities are of public interest. A vulnerability that simply allows users to deface the company's site, for example, are embarrassing for the company, but really serves no public benefit. A vulnerability that allows you to launch a nuclear rocket to anywhere in the world or allow the NSA to do dragnet snooping, on the other hand, would definitely be of public interest. And there are lots in between them.


Getting scanned on AWS Elastic BeanStalk As soon as I upload/deploy an application to AWS Elastic BeanStalk, it gets scanned for common admin pages even though it’s not linked to by any external website and I have not shared the DNS name with anyone.

If you are not familiar with it the DNS name for EBS is something like this:

{environment-name}.{random 10 character string}.{region}.elasticbeanstalk.com

I have a couple of theories:

There's a script out there guessing the dns name of the application
I think that's relatively hard given there is a 10 character random string in the dns name(I assume it’s random) plus the environment name.
There is a script out there keeping a record of some AWS owned IPs and regularly scanning every port.
Note: I am not using 80 or any other common port.
You can somehow query elasticbeanstalk.com DNS record and get a record of all DNS names under it.

I mean it’s not bad as the admin login page, URL is random and the page is secured.

But it’s just baffling how I am being scanned without having any website linking to my application

Q: Can any security experts explain the reason for this behavior?

Any input is appreciated

Any instance/ELB on the public internet will get a public IPv4 address. There are people/bots who constantly scan for vulnerable hosts on the internet, I'm no expert on the tactics they use but its entirely possible that they scan known ranges like AWS more frequently.

A google shows up several articles on the tactics that could be used e.g.: https://www.securitynewspaper.com/2015/10/15/how-to-scan-whole-internet-3-7-billion-ip-addresses-in-few-minutes/

As an example I recently tested this by creating an instance with no DNS name, just an IP address. It was scanned 22 minutes after being created.

Bottom line is if you're concerned about the security of your IP then dont put it on the public internet, if you have to then consider an IP whitelist to just allow your address or alternatively look at AWS WAF for rules to block malicious traffic.

As an aside this is possible because the number of IPv4 addresses is relatively small. The IPv6 range is much bigger so theoretically scanning all addresses will not be possible (or at least not easily)


Declaring "this is data, not code" to protect against injection attacks. What's the word for that? There are a variety of ways to make sure a receiving system understands "this is data, not code" so that it doesn't try to execute or interpret the data. To name a few:

Prepared statements, to avoid SQL injection attacks
Escaping JavaScript strings, to avoid XSS attacks
Encoding HTML entities, to avoid HTML injection

Is there a word or phrase that covers all these cases?

(I don't think there actually is a word for this, but if there is, I figured this would be the place to ask.)

I believe the term you are looking for is input validation and sanitization. It is general enough to apply across multiple variations of the attack as you mentioned above and more. It would also include preventing attacks such as buffer overflows by preventing the attempted execution of code with an input that exceeds the designed limits.

EDIT - to add notes according to more specific scope

In the specific use cases presented, you are addressing the Web based attacks and are more concerned with telling the client what is data and what is code. Using this specific example, we'll dig into the HTTP protocol a bit to show what protections exists for clients and servers specific to this type of communication. The terms may vary across other protocols, but I can't possibly be expected to write about every protocol's communication in a short answer.

The best place to start with HTTP is HTML - Hyper Text Markup Language. HTML is the basis for data communication from a server to a web browser on a client. The client has a set of libraries which allow it to properly interpret the data received and take action according to the pre-programmed logic. By default, all data received is treated as data unless explicitly stated as code. In HTML that is accomplished with a script block and it's where all client side scripting takes place.

Now, this can be a concern in the event that a malicious actor finds a way to inject an ad or modify server code to serve additional  blocks into the data stream that were not originally intended for the user to use. This is where injection attacks begin to take their place and need to be mitigated by both the client and the server.

On the client end, the client needs to ensure it maintains the latest updates and looks for flaws with any scriptable components within a HTTP session. Flash updates, the recent JavaScript zero day, and many other components demonstrate that the logic that supports client interpretation of server sent data is done properly. It's also important that the client prevent any type of attacks which allow the attacker to use a browser to exfiltrate data from the user's machine back to a remote server.

On the server end, the server must ensure that all requests are handled properly including the receipt of data either from GET or POST transactions. Failure to do so can allow an attacker to impact services or embed code into a previously benign web page. Data handling/input sanitization is the key here.

So the answer probably is "there isn't a set term" but it's because transactions are assumed to be data unless the markup language indicates otherwise. This is why clients can shutoff java script and still browse web pages. They receive all the same data (barring AJAX calls of course), but they don't interpret the data as code since the engine has been removed.


Null byte injection to run PHP? A website accepts form input and outputs it to the screen, but replaces every <? to <--? turning them to comments.

Let's say I POST the following:

<?php echo "xy"; /* arbitrary php code */

and I want to get it running. Is there any way to inject something between the < and ? characters that gets skipped during php parsing?

No. PHP will parse the php file looking for either <?php, <? or <?= (depending on the value of short_tags)

However, outputting <?php to the screen would not execute code. It would need to have been evaluated (eg. saved to a .php file in the server that you then run). This form is probably vulnerable to XSS, though.


How to protect a PC against sensitive data access by malicious app/driver As a software developer I frequently work with various USB-attached peripherals in the prototype stage and their drivers.

Sometimes the peripherals come from companies that I do not know well or otherwise can't trust 100%, so there's a residual risk that the peripheral device + its driver contain a malicious component. I am most concerned about industrial spying here.

Concretely I would like to protect the source code and other sensitive documents on the developer machine (to which I attach the peripheral and install the driver) from being read by malicious drivers / spyware and being transferred to %malicious_organization% over the internet.

Would a normal Antivirus / Windows Defender help me achieve this? The situation may be that the malicious driver has been custom-developed and hence may not be a well-known piece of spyware.

How can I best achieve my data protection goals?

How to protect a PC against sensitive data access by malicious app/driver

A driver, by definition, is part of the operating system. As such, whenever someone is able to place a malicious driver, it gets access at a system level of privileges. That means it can access every single bit of memory your computer has.

You lost the game.

The only way to effectively counter this are air-gap security. Ie. place your machine in a room without any link to the outside (and that would include unintentional RF radiation, eg by rhythmically bursting a PCIe bus, or by actually RF transmitting malicious hardware), and monitor personally who accesses the computer.

I'd love to say something uplifting about not having the driver installed in the hypervising operating system, but in a lesser privileged VM – but the reality is that you probably want to use the device in the same context that you're developing in (otherwise, you'd simply not install the device in a sensitive environment, at all), so that basically simply doesn't help.

Note that the problem doesn't stop at the software level – if your hardware is a PCIe, CardBus, PCI, AGP, PCMCIA, ISA, PXI, PCI-X, FireWire, Thunderbolt, or one of many storage device classes (Floppy, IDE, probably a lot of Sata devices, M.2,), typical "tightly coupled" buses like HyperTransport, AHB then it might get DMA – and thus, exactly that, Direct Memory Access, without any chance of the Operating system, an antivirus software or even just the CPU to interfere. Usages of this mechanism to read out, and exfiltrate, the contents of a PC's complete RAM have been demonstrated numerous times.

You use the USB tag, but you don't explain it in your question – USB itself doesn't give the devices DMA capabilities, but many USB host chipsets and device drivers actually have bugs that allow USB devices to essentially get memory access. Note that this leaves the "malicious driver" domain, and enters the "buggy host-integrated hardware" and "buggy driver" domain – and everyone having ever read a piece of consumer windows driver will agree that this class of drivers is the dominant one.

All in all, installing malicious hardware in your machines is pretty much the "evil maid" scenario, only that you are the evil maid yourself.


Alternatives for sending plaintext password while login Note: I've already read Is it ok to send plain-text password over HTTPS? and https security - should password be hashed server-side or client-side?, but here it's about a specific replacement method (see below).

After reading an article about a new authentication method on the Cloudflare blog, I looked at the POST requests that are sent while authenticating with "Developer Tools > Network". Many popular websites (Reddit, HN, etc.) still send the password in plaintext in the (SSL-secured) POST request (see screenshot below).
Is this login method still industry standard?
Is the following alternative more secure than sending plaintext password over HTTPS?

signup: client generates a random salt, and sends the tuple (username, salt, hash(plain_password + salt)) via a POST request. Then the plaintext password never reaches the server.

subsequent logins: the server has to send salt back to any client who tries to login with a given username, so that the client can hash with the same salt. So this means that the server is disclosing salt to anyone trying  to log in with a given username.

benefit: the server stores a salted+hashed password (which is standard) but also the server has never, ever, seen the plaintext password even once (so if the server is compromised, the risk is limited)

Notes:

since H = hash(plain_password + salt) now behaves a little bit like a new plaintext (see the 2nd answer of Zero Knowledge Password Proof: why is hashing the password on the client side not a ZKP?), then the sever can store (username, salt, server_salt, hash(H + server_salt)) in the database, instead of (username, salt, H).

to mitigate risks for replay attacks, the server can also send a unique nonce, along with salt for each login, that expires after one login attempt

the main goal here is that the server never ever has access to the plaintext password or a simple hash of it (that could be often reversed with a single rainbow table for the whole site). I'm ok with the risk that an attacker has to compute one rainbow table per user.

Example attack I'd like to mitigate: if the server has access to a plaintext password and it is compromised (example Spectre / Meltdown vuln.) then the user's plaintext password (possibly reused on other websites) could be stolen, before it is salted-hashed and saved to the database.

I don't see to how your proposal is better than existing client side hashing approaches, but I find it as more complex to implement than others. Unfortunately you don't describe a specific risk you are trying to access so I just assume the typical threats commonly seen.
Man in the Middle attacker
In this case it is assumed that some man in the middle has access to the traffic, for example because it compromised some trusted traffic TLS interception in a corporate firewall or got hold on a trusted CA as in case of superfish.
In this scenario the attacker gets access to H the same as they did before with plain_password. Since H is everything what is needed for authentication the attacker is thus successful and your approach does not add any additional protection here.
Hiding weak passwords and password reuse
A common argument for client side hashing is to not expose a weak or reused password to the server, but instead authenticate with a complex derived password. Your approach does this with hashing the plain_password with some user generated random salt and then send H and salt to the server on password setup.
While this works every authentication now requires an additional step: first it needs to retrieve the previously used salt for the user from the user and then it can use this salt to hash the plain_password. This additional step makes authentication more complex since first it needs to check the user with the server and later it can check the password. Additionally a trivial implementation of this opens an information leak since it makes it possible to check if the user exists in the first place (salt returned or not) without further authentication.
This information leak can be closed by the server returning some salt no matter if the user exists or not. Of course this cannot be just a random salt since otherwise an attacker could just check twice the same user and conclude that the user does not exist if the returned salt was different. So the salt actually has to be fixed for the non-existing user, i.e. derived from the user name.
And this also shows a path to simplify your approach: instead of generating a random salt by the user, storing it at the server and retrieving it later again, one could simply derive the salt from the user name at the client side. A simple salt=hash(username+domain) would be sufficient to generate a salt which is unique per domain and thus make both salt and H different even if username and plain_password get reused on different domains. And contrary to your approach no additional trip to the server is needed to first retrieve the previously used salt for the user.

In short: this simplified approach is basically sending hash(plain_password+username+domain) instead of the original password. The domain is added to make sure that even if username and plain_password are reused over multiple sites, the derived password is not reused.


How should I handle a spam account I don't control from sending spam emails with my username? A family member contacted me yesterday saying their email has been hacked and that some other family members received spam emails from their account.

For this example, lets say the hacked family members account email address is John1234@gmail.com. I checked my spam folder and there was what appeared to be an email from this family member. The senders name was John1234 and the subject read "Hey Dan", which is of course my name. I looked at the email address that the email was sent from and it was not the family members email address, John1234@gmail.com, but rather John1234@williamcody.com.

I informed the family member of what was actually happening and that their account was not hacked, but suggested a password change anyways.

Now, this family member has used the same username, John1234, for 10+ years and I'm sure they have been a part of many chain emails in the past. I'm assuming this spammer is getting the other family member emails from this or a similar method.

The question is, how can I prevent this from happening again? My spam filter caught the email, but other family members spam filters did not. The website the fake email account is hosted on looks like it hasn't been touched in a few years. Can I assume that the website owner is unaware?

Anyone can create new email accounts with "John1234", and those usernames are considered "public" so you have no control over that.

What is more interesting is how the spammer got a hold of the distribution lists. I would highlight the "change password" advice and make sure that proper hygiene is being practiced.


How much entropy is good enough for seeding a CSPRNG? I have some fundamental questions on using Cryptographically Secure Pseudorandom Number Generators (CSPRNGs).

What should be the size of the seed that I initialize a CSPRNG with? How often should I reseed it? and how to determine the size of the reseeded entropy?

Any pointers will be helpful.

What matters is entropy.

What makes a PRNG cryptographically secure is the inability of attackers to predict the next bytes. Precisely, there are three "security levels" that define the security, in the following model:

The attacker is given s bits of consecutive output from the PRNG.
The attacker's computing abilities are limited to 2k elementary operations.
The attacker is challenged with predicting the next bit from the PRNG, and must not be able to succeed with probability greater than 0.5+2-e for some value e.

Note that predicting a bit can always be done with probability 0.5 (with a purely random guess), so what we require is that the attacker cannot do substantially better.

In all generality, we normally want the PRNG to fulfil these properties with k+e ≥ 128. The "128" is a traditional limit. Basically, the attacker will try to enumerate possible seed values, and see what matches the known output; if the attacker found the actual seed, then he can predict all subsequent output with 100% accuracy; otherwise, the attacker knows nothing and is back to luck-based guessing, i.e. probability 0.5 for each bit.

To achieve this level, the seed shall represent an entropy of at least 128 bits. In fact, stating that "seed S has entropy 128 bits" really means "attackers who try to guess S and do so by successive trials in optimal order, starting with the most probable values, will succeed after an average of 2127 trials". The term "average" is the important one here: entropy is all about probabilities and averages.

To have 128 bits of entropy, you need at least 128 bits of data, because you cannot fit n bits of entropy into less than n bits of data. However, real-life "random" data is extracted from physical measures, and is biased, so it needs more bits to be represented. For instance, you can get some randomness out of the timing of keypresses from the user: biologically speaking, the user cannot reproduce exact keypress timings down to the microsecond, so the delay between two keypresses, expressed in nanoseconds, will "contain" about 10 bits of entropy -- but a one-second delay requires 30 bits to be encoded in nanoseconds.

In general, as an application writer, you do not have to do the complex job of estimating entropy: the operating system already aggregates randomness from physical sources, and computes these estimates. When you ask the OS to give you "random bytes" (by opening /dev/urandom on Linux systems, or calling CryptGenRandom() on Windows), you already get bits that are clock-full of entropy. So ask for 128 bits (16 bytes) and you will have a fine enough seed for your PRNG.

(The "128" is traditional. Current technological limit for the richest of attackers is close to 275 operations, and unlikely to increase beyond 2100 in the next two or three decades. "128" is considered elegant by cryptographers because it is a power of 2.)

If your PRNG is really cryptographically secure, then reseeding is not needed -- a need to reseed would actually count as a break, thus contradicting with the notion of the PRNG being cryptographically secure.

Many people and standard still insist on reseeding, mostly because of an established dogma that says that you must reseed, for reasons which are never actually specified. This dogma comes from much older days, when PRNG were not cryptographically secure, and actually were not running on computers, because that was before computers were invented.

Thus, you should reseed as often as it takes to keep your auditors happy, but do not worry about the security issues of reseeding or not reseeding: you do not reseed to achieve more security, but to keep other people happy and quiet.

(If your CSPRNG is NOT cryptographically secure, reseeding is unlikely to save your skin anyway.)


How can an account be accessed even though two-step authentication? Facebook uses two-step authentication or "login approval", which means that all unrecognized devices will have to enter a code received through SMS. Suppose my Samsung device is the only device that has been logged in to my Facebook account. What must the attacker do so that:

I won't receive any SMS (or at least won't see any)
I don't receive any e-mail about that
The attacker gains access to my account and can view messages/be active (liking, commenting)

What is the most realistic and possible scenario?

There are different possibilities from the top of my head:

the identifier of a legitimate device has been compromised (by a MITM with a downgrade attack, for example) and used to identify as such device,
the mobile phone has been compromised as a whole (forwarding and hiding/deleting SMS and emails),
SS7-based attack on your mobile number in combination with a compromised email account.


What is nuke it from orbit? I was reading this
Windows 2003 Enterprise infected by Conficker; post-infection problems continue
And they talk about nuking it from orbit (which apparently means wiping out the system and starting over) or at least doing an OS reinstall with full format
How are the two things different? Or is it because it is a server thing that these two mean different things?

I say we take off and nuke the entire site from orbit. It's the only way to be sure.

Probably the origin of this saying.

In the context of having your computer infected by a virus: even if malware seems to be removed, it may not be - and the only way to be sure it's completely gone (and even then it's hard to be 100%) is to completely wipe the system and start fresh.

We all know what happens when you don't nuke Xenomorph's from orbit. Don't expect any better from malware.


Passwordless login over email - security considerations I'm proposing the use of a login system that sends a one-time login token (with high entropy) via email to the user. After using the token, the user receives another token via email and the previous token is invalidated. The new token is sent with information about the use of the last token, so if someone does gain access to a token somehow the user will know.

The implementation I have has received great feedback as far as UX goes, but I'm facing a lot of pressure from non-techs to "prove" that this is secure. Additionally, our marketing team is concerned that this will be hard to teach customers about.

Aside from the lifetime of the one-time login tokens (they can last a couple of weeks), what makes this any different than forgotten password functionality? Additionally - and this is where this question isn't as easily answered as others that are relatively similar here - are there any respected companies who have implemented a login scheme like this, and are there any papers you can recommend I point to to prove the security of this system?

You are correct that the security of your system is similar to that of most password reset systems. It is as secure as the email addresss - no more and no less. Be aware that some password reset processes ask additional questions (e.g. what's the name of your first pet?) which do provide some additional security.

You will have a hard time persuading a non-tech of the security of this. One approach would be to do a Threat Model of your system and show this to them. I doubt they would read it though. The thing is, computer security is far from perfect, so you really have to think about what happens if it goes wrong. If you have a breach, it may seem much harder to justify your non-standard system. There's a lot of be said for doing the same as others.

I have seen live systems that take your approach, including Doodle and RT. Some surveys also do it.

I'm curious why you reset the token after it's been used. What was your thinking?

One threat to be aware of is browser search bars. If a user has these installed, all the websites they visit may get sent to the search engine. This could end up with http://yoursite/token/ being added to Google's index, which is clearly not desirable. Your approach of one-use tokens actually prevents this. Another approach is to always use "no index" meta tags or robots.txt.

What you have created here is what I'd call "poor man's single sign-on". You may be aware that there are some standards for web single sign-on, including OpenID, OAuth, Mozilla Persona, and more. However, none of these has gained a critical mass.


How does DuckDuckGo know my native language even though I am using a VPN in a country with a different language? I recently started using a VPN and I've felt more comfortable browsing the Internet. My VPN allows me to select another country through which my traffic is routed to make it appear I'm located in that particular country. "What's my IP" and similar services show my IP address located in that country as expected.

Search engines, however, are apparently not fooled. As I go to Google, for example, the front page is in my native language and it says my true country of origin at the bottom of the page. I was aware that this happens, as a VPN is not truly a means to make myself anonymous, and companies like Google can track my true location (I assume they do this for example by looking at the country specific top-level domain of the sites I visit?).

But what puzzles me though, is that other search engines, such as DuckDuckGo, which promise not to track their users in anyway, can also see my true country of origin. The front page of DDG also appears in my native language (not English).

So how is it that DDG and other "non-tracking" services see my true location without "tracking" me? Even when my IP address is located somewhere else, what gives my location away in such an obvious way that DDG can still claim not to track me?

One possible explanation is that DuckDuckGo is using the headers that are sent in your request to determine their display.  For example, it is very common to use the Accept-Language header to determine in which language a webpage should be displayed.  This header is set by default in all modern browsers based on the language preference settings.  My browser, as an example, sends Accept-Language: en-US for all requests, letting the target site know that they should attempt to send back US based English if possible.  This does not require any sort of tracking to be used.

If you visit https://duckduckgo.com/settings you can see what the language settings are.  The default language is Browser preferred language


Is installing malicious add-ons via drive-by attacks the only way to add new toolbars to browsers? Some attacks on web browsers consist in installing new toolbars on the browser of the user (which is just a small aspect of browser-hijacking. My question: is installing (malicious) add-ons (via drive-by download attack) the only way to add new toolbars to browsers such as firefox, internet explorer and google chrome ?

Simple answer: No

Any attack which compromises your machine could add toolbars to your browser.

However, this is a very different type of attack, and to be honest, any attacker who has full control of your machine is likely to do worse things, like making you part of a botnet, adding keystroke loggers etc.


Should Content in  Blocks Be Escaped The title pretty much says it all. It seems counter-intuitive to escape inside a <noscript> block because any js that an attacker is able to inject there shouldn't be executed. But, I'm still pretty new to this, so I thought it would be prudent to ask.

For clarity, this is the context that I'm talking about:

<noscript>
<img src="<?php echo 'Should I escape this url' ?>" />
</noscript>

Yes. You should always escape untrusted data. Here's an attack for your snippet (pseudocode):

<noscript>
<img src="<?php echo 'you should always escape everything,
                dependeing on the context. This context is url in an attribute,
                you should escape it appropriately. otherwise " />
                </noscript>
                <script>alert("you will be vulnerable")</script><noscript><img "' ?>" />
</noscript>


How to Investigate Wi-Fi Intrusion and where to look for evidence? I'm trying to figure out how to configure a network so that I can tell what an intruder did (in the past) while on the network after they are detected.
eg. If someone with a wi-fi enabled laptop parked outside my home and connected to my home network because he was able to crack my weak encryption. and if he were to do some fraudulent activity from my network, how can I configure my network and where would I have to look on the network to see what he was up to?
What devices would be able to log valuable information and how would I make sense of this information?

Most routers (even retail wifi units) have an admin screen that lists all the active clients that have been allocated an IP address by DHCP.  This usually lists the MAC address of the client too.

usually they look like this:

CLIENT NAME       IP ADDRESS       MAC ADDRESS
android_blah      192.168.1.10     AA-BB-CC-00-00-00
my_pc             192.168.1.11     DD-EE-AA-00-00-00

If you do not recognise the client names - then a handy tip is to take the first 3 octets of the MAC address and google them (e.g. AA-BB-CC) and this will tell you the manufacturer of the device which could help determine whether it really is inside or outside of your home.


Regenerating CSFR token in AJAX requests I would like to create a new token for each request and would like to us the following template-

 <script>
        var current_token=<?php echo $_SESSION['csrf_token']; ?>

            $.ajax({
                type: "POST",
                url:"script.php",
                data: {'token':current_token},
                success: function(data) {
                                var result=JSON.parse(data);
                                current_token=result.token;
                            },
                error:function(error){
                                console.log(error);
                }
          });
  </script>

here is script.php

 <?php

     if($_POST['current_token']==$_SESSION['csrf_token']){

          //do your thing
          $token="new token" //generate new token here
          $_SESSION['token']=$token;
          $response['token']=$token;
          $out=json_encode($response);
          die ($out);
    }else{
         //request failed - handle as error and ask to re-login or whatever
    }
?>

explanation-

You send your AJAX, validate the session token and post token
If successful, generate new token
Update the token in $_SESSION['token'] and also send the new token
back
Use the success function retrieve the token and update in your
JavaScript

It this a good idea? Or does this create a new vulnerability like an XSS spoof ?

Before I answer this, I should ask: is there a reason you think changing the anti-CSRF token on every request is necessary, or even beneficial? I don't want to say that there categorically cannot be a good reason, but I can't think of one. The rest of the answer is based on that.

Is this a good idea?

Not really. There's no need, and no good reason, to change the CSRF token on every request. In fact, this is likely to break stuff. For example, if your user has two or more tabs open to your site, they'll have the same session and thus the same server-side anti-CSRF token, but each will run their own javascript with their own local variables. You could get around this by using something cross-page, like client-side session or local storage, but why bother? The whole exercise is almost certainly pointless overcomplication for no gain.
Additionally, if you're performing your state-changing requests via AJAX rather than via HTML forms or similar, there's an easier way to prevent CSRF. Just add any non-standard header name to the request (for example, X-CSRF: very bad!) and on the server, make sure that non-standard header is present before processing the request. Cross-origin requests can't add non-standard headers without a CORS preflight; if you don't implement CORS support, or you do implement CORS but don't ever allow another origin to add that header, you're done. This has all sorts of advantages: no need to securely generate unpredictable tokens, no need to store extra state on the server, no need to synchronize server-side state across a cluster, no risk of side-channel timing attacks or similar, no worrying that the client might be using an outdated anti-CSRF token...

Does this create a new vulnerability like an XSS spoof?

I have no real idea what an "XSS spoof" is supposed to be. Your scheme, as described, does not introduce an XSS vulnerability unless the attacker can somehow control the value of the anti-CSRF token, and your client=side script does something more exciting with it than just stick it in a variable, and add it to AJAX request bodies.
There are some weaknesses of the proposed scheme, such as the risk of a timing attack due to the early-exit string comparison (on the server). Realistically, that's probably not a meaningful risk (in fact, the rapidly changing value of the token would in fact make this already-low-risk threat even less of an issue), but why take the chance? Besides, the much likelier issue would be in how the anti-CSRF token is generated and stored on the server.


Is just PIN and password without any hardware token considered to be 2FA? When using online internet banking, I have to use my 6 digit pin and a password to authenticate into the system.
There is no hardware token used in this example.
Is this considered as 2 Factor Authentication?

Short: No

  Two-factor authentication refers specifically and exclusively to authentication mechanisms where the two authentication elements fall under different categories with respect to "something you have", "something you are", and "something you know".

This only uses "something you know"

Full answer


Recovering truecrypt full disk encryption with wordlist I'm dusting off an hold drive and unfortunately forget the password.  I'm going to run a word list against it using TrueCrack however I'm a little confused on how to extract the volume header to run tc against.

https://www.truecrypt71a.com/documentation/technical-details/truecrypt-volume-format-specification/

The first sector of the disk contain the MBR (446 bit MBR + 4 byte partition table).  The MBR is obviously a truecrypt MBR due to the fact that I get prompted for a password.  I assume that the TC MBR code tries the password against the very first bytes of the active partition.

I may be wrong because when I pulled out the disk I got an error stating "Failure to read disk 0 sector 62".  The documentation above also makes it seem like more than just the first 512 bytes are used.

My goal is to simply DD the volume header (or whatever I need) off of the drive and run Truecrack against it.

The TrueCrypt MBR does not do any password checking, as it'd be impossible to implement code for AES, Twofish, Serpent, SHA512, RIPEMD-160, Whirlpool, and PBKDF2 all in the space of 446 bytes in real mode. All the MBR does is load the rest of the bootloader (this is called a staged bootloader). The bootloader is what is responsible for providing you with a prompt, checking the password, and finishing boot.

The URL you linked for the volume format is only for the volume itself, which does not include the MBR. It most likely starts at the TrueCrypt partition, not the very beginning of the disk.


What happens to messages sent in IRC without voice? I was in an SSL secured IRC earlier and accidentally pasted and sent something sensitive in a channel in which I didn't have voice permissions.

I got the error:

You need voice (+v)

I'm new to IRC and don't know much about it, but was my message still sent to the server, can administrators of the room still see it, etc? How bad can it be, say if what I sent was my password?

There are a few different aspects to this question:

Did the message reach the server?  Yes.
Can the IRC channel operators see it?  No.
Would it be possible for an administrator on the IRC server to see it?  Normally such things are not logged but it's their server so they could do whatever they want with the information that goes through it.
Could it get intercepted elsewhere in the process?  It depends if you used a secure (SSL) connection or not.  If you didn't, such a text message could be spied on its way to the server.


How can I explain the concept of public and private keys without technical jargon? Possible Duplicate:
  Principle of asymmetric algorithm in plain english

In the spirit of How can I explain SQL injection without technical jargon?, do you have any suggestions on how to explain the concept of a key pair to someone who's not well versed in technological terms?

Note: This answer is aimed at really non-technical people, I have tried to make it understandable by a child, please don't be offended!

Lets say I want to send something to you, but I don't want anyone else to be able to read it. The first thing that comes to mind is encryption! Encryption gives confidentiality, right? It sure does, but there are some problems to address.

Classical, or symmetric encryption requires some kind of shared secret. In the computer world, this is called a key. The problem is, in order to communicate confidentially using symmetric encryption, we both have to know the same key. We have to communicate this key to each other by some secure means before we can use it. It's a chicken-and-egg situation, we need to send the key confidentially in order to have a confidential channel.

One solution would be to meet up somewhere physically, agree on a key (which is just a really big number), and then go our separate ways. With this arrangement, we know we are the only two people who know the key, and we can happily transmit messages to each other using it, in the knowledge that nobody else can read those messages.

This solution does not scale well, and in the world of the internet when we might want to talk securely to a few dozen parties a day, that would be a whole bunch of secret meetings to set up, a whole bunch of keys to keep track of, and a fortune in travel costs.

Enter some really clever mathematicians. Asymmetric cryptography is essentially a smart bit of maths that allows us to use a pair of keys. One key for encryption, and one key for decryption. What's more, it is impossible to generate one key from the other.

Think of it like this; the encryption key is a padlock. You just click it closed, and it locks. The decryption key is like the padlock key.

It works like this; I want to communicate with you securely, but we have never met, and share no secret.

You send me your padlock.
I write my message to you, put it in a box, and lock it with your padlock.
You keep hold of your padlock key at all times, so you are the only person who can unlock the padlock. Once I have locked the box, not even I can open it, because I don't have the key.
Then I send the box to you, safe in the knowledge that you are the only person that can unlock it.

Someone watching our traffic can see you send over your padlock (encryption key). But they can't do anything with that padlock except lock things that only you can open. They can't examine the padlock to figure out how to make a padlock key for it, the mathematics of the system ensure this.

They then see my message to you, locked away with the padlock, but they don't have the padlock key, so they can't do anything with it.


Short digital signature I want to digitally sign messages with strict size limitations. I am looking for digital signature algorithm providing very short signatures. (as short as possible)
Which secure algorithms can I choose? The digital signature check will be performed on server-side (JAVA) as well as on client-side (Android, iOS).

There are two broad families of digital signatures in common use: those based on RSA, and those based on a discrete logarithm. RSA signatures are the same size as the key, and a minimum key size for reasonable security is 2048 bits (256 bytes). There are many variants of signature schemes based on the discrete logarithm, but all have the same signature size anyway: twice the size of the key (the signature is a pair of numbers). Elliptic curves give the best security at a given size of numbers involved, and smaller numbers are better for performance anyway, so there's no reason to look for anything else. The smallest curve size for reasonable security is around 256 bits. So the smallest signature size is 64 bytes.
Both ECDSA with the curve secp256r1 (also known as “NIST P-256r1” and other variants) and EdDSA over Curve25519 (also known as Ed25519) are widespread, and they give the smallest signature size, so there's no need to go and look for anything exotic.


Mutual Authentication and Authorisation with Certificates from various CAs Edit:
Having read this question and answer I have a bit more of an understanding. My question now then, is: can I use a certificate that a user has had signed by a registered CA such as VeriSign, GoDaddy, etc, in place of signing a certificate myself? If so, what mechanism do I need to use to verify it? Will CRL or OCSP have details from all CAs or will I need to check their individual registers?

Original:
I'd like to know how I verify the validity of certificates from various CAs for the purpose of mutual authentication on a website, or whether this is even an issue to be considered?

I am in the process of learning about mutual authentication and how it works, along with certificate signing in general so any pointers or references to read to help understand this subject would be appreciated.

Currently I have a simple Ubuntu Server running in a VirtualBox that I am using to experiment with. This is running nginx and mysql, both of which are configured to require TLS/SSL. The next step I want to implement is mutual authentication between nginx and the client browser; I have successfully set this up on the server using a self-signed CA certificate. However, I am struggling to understand how the certificate sent by the browser is verified.

I have a public/private key pair on the host OS, and I could feasibly generate a certificate signing request and send it to the guest server, which could sign it against the CA certificate and return it to my host. This certificate will be signed, but not by a registered CA. Taking this one step further, I now visit another website that I do not control: does it need to sign my certificate also?

My understanding is that once a certificate has been signed that is it, it does not need to be signed again except for renewal. This is only true if signed by a registered CA such as GoDaddy, CACert, etc. Therefore, back to my website, how do I know whether this is a valid certificate? If I use CRL or OCSP to check whether it has been revoked or not, will it check for all providers or just the company who maintains the list/server?

Assuming that one way or another I can validate the authenticity of the certificate, how do I then use that to authenticate (or, I suppose more accurately, authorise) the specific user? Do I need to store a copy of their public key and check against this or is it possible to extract some unique detail that would enable me to authorise them?

This is a new area for me and I have undoubtedly made some incorrect assumptions as well as exposed some gaps in my knowledge and understanding of the subject. I'd appreciate any answers that will help correct these. Also, if the question isn't specific enough for forum rules I apologise and any guidance on how to better frame it so it doesn't violate the rules would be helpful.

Mutual/client authentication via certificates is not a common configuration, thus you may not find much information on this topic, e.g. for nginx, as you might expect.

That said, you asked:

"Can I use a certificate that a user has had signed by a registered CA such as VeriSign, GoDaddy, etc, in place of signing a certificate myself?"

Yes.  Let's assume that your client has a certificate, issued by one of the above CAs.  To get that client to send its certificate to your server (e.g. nginx), you need to configure your server with a list of CAs that it will trust.  As part of the SSL/TLS handshake, the server "requests" that the client send its client certificate by sending to the client a list of CAs that the server trusts; the client can then choose one (among possibly several) certificate that has a "trust path" to those of those CAs that the server trusts.

This means that on the server end, you can configure the list of CAs you trust, using their certificates (and public keys); you do not need the private keys of the CAs for this.

"If so, what mechanism do I need to use to verify it? Will CRL or OCSP have details from all CAs or will I need to check their individual registers?"

OK, this is where things might be a little tricky.  The practical answer to this question is "it depends on the software/application you are using".  Since mutual/client authentication is not very common, many applications may not have CRL/OCSP functionality for client certificate verification implemented.  But let's assume, for the sake of discussion, that nginx (or mysql) can do this.

Within an X509v3 certificate itself, there are extensions which define where to find the CRLs for verifying that certificate, and/or for defining the OCSP responder to contact for verification.

The CRLs relevant to the presented certificate should be defined, in that certificate, by the CRL distribution points extension.  There are many possible formats for this extension; the linked RFC 5280 documentation goes into specifics.  But this extension, if present, is what any software (such as your website server) would look for, in order to discover where/how to get any CRLs that might mention this certificate.

The URL for the OCSP responder to contact, for example, might appear in the "authority information access" extension of the certificate.  For example, using openssl x509 -noout -text < /path/to/cert.pem on a certificate, you might see this displayed like so:

Certificate:
    Data:
        Version: 3 (0x2)

        ...

        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE

            ...

            Authority Information Access:
                OCSP - URI:https://ocsp.example.com

Thus the server in question has to parse these attributes/extensions out of the client-provided certificate in order to discover who to contact, for that certificate, for CRLs or OCSP data for that certificate.  In most cases, the CAs signing/issuing the certificates will also be the organizations maintaining the CRLs and/or OCSP responders for those certificates.

Hope this helps!


Should I use the certificate serial number or the subject key identifier to look up public key? I'm designing an API authentication mechanism similar to the one AWS use. As part of that, I need to look up which public key belongs to which user to verify. The public keys come from x509 certificates that we issued to user, so I know they have both serial number and subject key identifier (SKID). Should I use the serial number or the SKID as a unique ID?

The advantage of SKID is that it's a hash of the public key so it can be independently computed from the certificate. However, the serial number is simply an integer, much easier to deal with.

If you only accept certificates issued by you, and you validate that fact, then using the SKID has no security benefit over the serial number. If you use the serial number, and accept self-signed certificates (or any other certificates from CAs who aren't you), an attacker who knows the public key can impersonate users.

Otherwise, there is no difference security-wise. Of course, you'll have to make sure the SKIDs you issue are really unique, and the attacker can't e.g. abuse the fact that your backup signing infrastructure can't doesn't care for duplicates.

As your answer indicates that all certificates are signed by you, you I'd suggest to use SKIDs. You can make your signing infrastructure spare some bits out of your desired int width (e.g. 64 bits), and use those spared bits to store the signer certificate, either on the "storage side", or already with the signers, then you can ensure uniqueness, too.


Client Cert Authentication: Accept cert in request or retrieve from host? Is it more secure to retrieve a client cert from their host rather than accept the cert presented in request?
Example:

B2B
Client pre-shares public cert with me
I store public cert in database
Later, client sends GET request + cert to my HTTPS endpoint

Endpoint has Enforce HTTPS and Require client certs set to true

Python code takes client cert from GET request and compares the properties to those in the pre-shared cert from database (cert pinning of sorts)

valid_not_before/after
issuer
common_name
etc.

Python code then:

Determines OCSP responder url from client cert in request
Retrieves issuer cert
Creates an OCSP request
Verifies OCSP response is GOOD

Only then does the api perform work for the requestor

Question:

Is it possible/is there any benefit to instead:

Parsing the hostname from client cert in the request
Retrieving the client cert from client source (hostname.com:443)
Then using this retrieved cert to compare with the pre-shared cert from database and make OCSP calls, etc?

Hope this makes sense.

No, there is no benefit to doing that, and in fact it likely opens a security hole. Let my explain.
First, a metaphor. A bouncer at a bar asks for your ID. The normal system is for you to present your ID (metaphor: client cert), the bouncer checks that the ID legitimate (metaphor: validates the issuer, revocation, etc), and checks that the photo matches the person standing in front of them (metaphor: the client cert will digitally sign part of the TLS handshake using their private key). You are proposing that instead of accepting the ID presented to you, you should take their name and go retrieve the ID from a government database. This is only necessary if you don't have a good way to check legitimacy of the ID on the spot. That may well be a weakness of physical IDs, but it is not a weakness of digital certificates. If the issuer signature is valid and the cert is not revoked, then it is authentic and you would get the same certificate from the CA or domain owner. So the extra lookup is not necessary.
I said your suggestion might open a security hole; let me explain:
As part of TLS client auth the client will perform a "proof of possession" by signing part of the TLS handshake with the private key that matches the certificate. If you (the server) go off and get their "real" certificate, maybe they have multiple valid certificates, how do you know that you're getting the one that matches the private key they're trying to use? Also, how are you going to do the lookup, with a name (DN) that the client gave you? How do you know that they are not lying to you and getting you to look up someone else's cert? So the extra lookup may in fact introduce vulnerabilities.


Does someone need to be connected to my network to sniff HTTP requests? TL;DR Would a potential attacker need to have my Wi-Fi password and be connected to my network in order to read HTTP requests?

Over the past year or so, I have made a few DIY home automation projects. Included in this is a garage door opener. The basic premise of which is that when I want to open the garage, the home automation hub sends an http (not https) GET request (e.g. 192.168.1.xxx/openGarage) to the DIY IoT device which then opens the garage. (The IoT device will trigger the garage whenever it receives that specific /openGarage request)

However, for some time now, this has worried me. I was wondering whether an attacker who was not connected to the network would be able to intercept the HTTP get request (192.168.1.xxx/openGarage) and then be able to replay this get request in order to open the garage without my knowing.

So, my question is: would an attacker need to be connected to my home network in order to intercept this GET request (/openGarage) or would they need to bee connected in order to see this?

Thank you in advance for your help,

Kind regards, Rocco

P.S. I understand that making this request an https one instead would obfuscate the request, however, it is quite hard to implement proper SSL encryption on an ESP8266 which is what I am using for this IoT device. Thus, I am willing to hinge my security on the strength of my WPA2 password. That is, if an attacker would need to be connected to my network in the first place to intercept the request as per the above question.

Yes. An attacker would need to be on your network - either wirelessly or wired - to intercept an intra-network HTTP request. If it left your network for the broader Internet, the attacker could potentially intercept it anywhere between your property and the server, but with the server on the same local network the traffic won't leave your router. As WPA provides both encryption and replay protection, an attacker wouldn't know what message you are sending, nor would they be able to replay it (although traffic analysis - such as noting the packet size, and/or noting that a message for a particular MAC address is always sent before the garage door opens - would be possible).

However, by implementing your system this way, you're opening yourself up to the massive world of web application / web service security vulnerabilities. As a trivial example, you service right now is almost certainly vulnerable to CSRF; if any machine on your network visits a web page with 256 invisible image tags on it - one each from  to  - your garage door would open. JS could be used to iterate through even much larger spaces very quickly.


How secure is this two factor authentication? I am working on an App that has a login page with a field for username and password, if the password is entered correctly it then asks for the users pin (4-digit code).

My question, does having a pin as the second factor to login really make it any more secure?

If a hacker brute forces a users password, wouldn't using brute force against the pin be even easier since it's only 4 digits and only 0-9?

Also, is there anything else I could do to make it more secure? (Without adding another step to login)

So two factor is when you authenticate with two pieces of information:

Something you know, passphrase for example
Something you have, yubi key, RSA token or a google authenticator

This way if an attacker has one - which in most cases will be a passphrase it will not authenticate without the piece you have. Your pin will only work if it is a OTP (One-time-password) otherwise you have actually just added a second password to your login process which will only slow an attacker not prevent them from breaching your site given the first passphrase.


Is CAST5-CBC as supported by OpenSSL an authenticated encryption method? I'm looking to encrypt some files using a simple cipher plugin. I have access to using AES-256 in CBC mode, but this doesn't offer message authentication and I'd have to build my own HMAC for it.

CAST5-CBC is one of my options. Is CAST5 in CBC mode an authenticated encryption method or do I still have to build my own authentication into it? AES-GCM is unavailable to me, sadly, as I would use that.

The reason AES-CBC isn't an authenticated mode has everything to do with the CBC and nothing to do with the AES. CAST5-CBC isn't inherently authenticated either; changing one bit in the IV changes the corresponding bit in the first block, and there's no way to detect it, because that's a result of the CBC construction and not of the cipher.


Does shodan JSON API use my IP address? I want to find out if shodan uses my ip adresse to query the target after sending this HTTP request:  https://api.shodan.io/shodan/host/{target_ip}?key={MY_API_KEY}

so is shodan API a passive or active scanning tool  ?
the same for searching in shodan's home page ?

When you use Shodan your system is not directly contacting the target system, what you're doing is querying the database that Shodan has built up from their port scanning runs over various IP address ranges.

The API performs the same kind of queries as you can do from the main Shodan website.

In terms of your question of Active v Passive, it depends on perspective.  From your perspective it's passive in that you don't send traffic to the target system.  From shodans perspective it's active in that they do send traffic to the target system


what is wrong with openssl ciphers? I used openssl recently and noticed that in the cipher list there is AES (what else ) and then I saw many rarely used ciphers like camellia and seed, then I saw stuff like rc4, rc2 ...

Why are insecure outdated ciphers so widely supported by openssl?
Would it not be better to support libraries for stronger ciphers like twofish or the new GOST cipher?

In "ecparam" I even saw that many modern curves were missing.

OpenSSL is an extremely widely used library. There are many legacy systems that only support old ciphers, and so the OpenSSL project is conservative in removing support for them, preferring to allow the user to configure allowed algorithms. This is in contrast to a library like NaCl, which is highly opinionated about algorithms.

As a side note, just because you have not heard of camellia does not make "no-name".


What are the risks of storing passwords in a GPG encrypted file? I currently store my passwords in a text file encrypted using GPG -e (specifying my own public key). When I want to lookup a password I'll do something like

gpg -d passwords.gpg | grep <sitename> | less

and when I want to add a new password I'll decrypt the file, edit the file and then encrypt it again.

What are the potential risks in this strategy? Are there any security issues to doing this compared to using something like Password Safe?

Your biggest problem is system compromise. If you store your key encrypted under a strong passphrase, then this is equivalent to the risk with a password manager (in fact if this is any indication, a lot of password managers don't derive encryption keys from master passwords correctly, so you're probably better off with gpg which does). So if someone roots your system and then you unlock your key, they have all your passwords. This is the same with any password manager that runs on your system.

If you don't encrypt your gpg key though, anyone who gets access to your system, even when its off (e.g. steals it) can read your key, decrypt your file, and get your passwords. This is worse than a good password manger (e.g. LastPass, KeePass, or even the OSX keychain).

Your second biggest risk is that that shell command writes tmp files to your system even if it deletes them (since deleting a file does not overwrite the data and it can be recovered with software). GPG might write temp files, grep might write temp files, less might write them. As might your shell. Moreover, since the last three of these are not meant to be secure, there is no reason why they might not decide to do that at some point in the future. On the other hand, a decent password manager would take steps to make sure it never wrote your clear text to disk. It could even only store your data in locked pages that don't get swapped to disk.

On the purely cryptographic side your max key size in gpg is probably 2048 bits. This gives you max 112 bits of security. To get something equivalent to AES256,  you'd need a 15360 bit key. This is the least of your concerns, but it still is one. Password managers usually use symmetric crypto so they can use AES128 or AES256.


iCloud Security Concern: browser session authentication storage after 2-factor? Does anyone know how Safari or Chrome stores a www.icloud.com session authentication after logging in and passing 2-factor authentication?  Is it stored in an encrypted cookie?

My concern is, if logging into iCloud from someone else's device (or browser), this session cookie could be stored. A malicious person, perhaps unknown to the system owner, could grab the session cookie and username/password from logged keystrokes. Now this person has bypassed 2-factor authentication and can access:

iCloud Keychain, iCloud iOS Backup (with password attack) and much more iCloud data including calendar, contacts, notes, photos, etc...

It seems like a big risk because many people store website passwords, including passwords to encrypted backups (Time Machine), on the keychain. This type of attack could expose all of this.

Appreciate your input and any steps you take to avoid this.

While cookies can be stolen and sometimes used to impersonate an active user, there are several mitigations that can be used such as browser fingerprinting or verifying the IP address of the requests.

By far the best way to keep your account secure is to Log Out when you're done with your session. On a properly implemented system this will invalidate your session on the server side, so even if the cookie is stolen it it no longer works.

2 factor authentication is a great way to protect yourself on a public computer. The only real concern is that an attacker could use your account before you log off, or what you're doing during that session could be snooped on if the computer was compromised.

Edit: One last thing. These cookies are marked in a manner as such that the browser will only send them over a secure (TLS/HTTPS) connection so they aren't intercepted by monitoring the network.


Force connected devices to use http rather than https I am very new to MITM attacks and have been faffing around on my home network today..

When sniffing my iPhone trying to connect to some mail accounts I have noticed that it shows a message stating the connection is unsafe, then asks if you want to just continue or close the connection. If continue is pressed it will send the email and password in plain text.

Anyway, I was wondering if there was any way to prevent any connections via https and force all through http. I'm not concerned if it prompts the user or not.

If you aren't concerned about the user being prompted, then you intercept most HTTPS connections by proxying them.  Instead of allowing the user to directly connect to the site they've requested, you connect them to a intermediary you control, and then use it to connect out to the to site that they've requested.  This way the client's HTTPS session is terminating on your box, with your SSL cert that you own the private key for, and thus you decrypt the client-side traffic, and since it's your proxy that is then making the connection out to the server they actually wanted to talk to, your proxy is now the client for that SSL connection, and you have full access to the traffic from that side as well.

This will prompt the user because of course your SSL cert, the one on their server the users are connecting to, will not be a valid cert for the sites they're actually trying to access, so client apps will (or should at least) view this as an attack and warn the users not to trust the connection.  As P4cK3tHunt3R mentioned, you can avoid the warning by installing your cert as a trusted root on the client devices, in which case they will no longer be able to discern (generally speaking) that the cert is not in fact valid and trusted for the site they're trying to connect to.

Aside from proxying, there are other ways to downgrade connections as an active MitM, such as SSLStrip, which will work in some cases, and not in others.

In some cases, proxying works even better than advertised, with mobile apps particularly, which are notorious for ignoring certificate warnings and happily accepting untrusted certs without bothering to inform the user than anything is amiss.   In other cases, it won't work at all, due to practices like certificate pinning where a browser or other application only trusts specific certificates, and will refuse to accept your certificate, even if it would otherwise be valid and trusted.


Designing and implementing a secure epayments system with RESTful API I want to design and implement an epayments system (I will not be handling credit card payments). The system will have a RESTful API. I am already familiar with RESTful servies, and have built a few in my time.

However, this time round, security is of paramount importance and I want a system that is as robust against external attacks, as anything out there (e.g. Paypal).

The way I see it, there are two points of attack:

The physical machines (servers) and the network they reside on
Attacks via the exposed RESTful API (man in the middle attacks, snooping etc).

Paypal, which is a model of what I want to replicate, provides a RESTful API, using OAuth etc, so I know it is possible to provide a secure RESTFul API to sensitive data.

So my question basically decomposes into the following two questions:

A. What technologies/practises are employed by companies such as Paypal, to ensure that their machines are not hacked or compromised?

B. Is OAuth the way to go to present a secure interface to the world? - or can this be improved?

You might think that your project differs from a decent Content Management System. But in fact it's not. You should reinforce what's paramount to every software project: Testing and high code quality. Security is not only subject to the API itself but to the software behind.

Using a programming language that forces a static type system is a good start. Then do excessive Unit and functional testing. Especially what happens if the client does not behave in the predicted manner. Then you can do some pentesting.

Those strategies apply to a high-security application as well as a little app like a CMS. I would also suggest a language like Java with a compiler. So if you introduce any code inconsistencies they will break the compiling process.

The server itself will likely to be secured like every bigger server. But that's not my best expertise.

You see? Nothing new and fancy here...


gnu gcc source archives signed with expired GPG key? I'm in the course of rescuing a legacy app that got left behind and turned out to be needed on rare occasions, one of which occurred yesterday. I need to rebuild some libraries and the libraries have a strict dependance on gcc > 6.0 which the server sadly lacked by a mile. So I went looking for a newer gcc and found mirror sites here:https://gcc.gnu.org/mirrors.html such as http://www.netgull.com/gcc/releases/gcc-9.3.0/. (Aside: so many sites still answer over http, not https, oh yay!)
The gcc-9.3.0.tar.gz archive signature in gcc-9.3.0.tar.gz.sig is with the key for Jakub Jelinek listed on the gnu.org page, fingerprint 33C2 35A3 4C46 AA3F FB29 3709 A328 C3A2 C3C4 5C06.
This key is in the ancient keyring at https://ftp.gnu.org/gnu/gnu-keyring.gpg, and has expired.
Why are recent versions of gcc, of all things, being distributed this way? Is there some refreshed version of this key I'm not finding? Or a different mirror site using a different signing key?

The pedantic answer to your question is: when gcc-9.3.0 was released, the key was not yet expired:
$ gpg --verify gcc-9.3.0.tar.gz.sig gcc-9.3.0.tar.gz
gpg: Signature made Thu 12 Mar 2020 07:32:47 AM EDT
gpg:                using DSA key A328C3A2C3C45C06

The signature was made in March 2020, but the key expired in September 2020:
gpg --list-keys A328C3A2C3C45C06
pub   dsa1024/A328C3A2C3C45C06 2004-04-21 [SC] [expired: 2020-09-10]
      33C235A34C46AA3FFB293709A328C3A2C3C45C06

So, the fact that it's expired now is not a cause for concern.
What is the cause for concern is that it's a 1024/DSA key, which is probably not considered sufficiently strong these days. However, I can also see that the author has a newer key created in May, 2020:
pub   rsa4096/6C35B99309B5FA62 2020-05-28 [SC]
      D3A93CAD751C2AF4F8C7AD516C35B99309B5FA62

So, perhaps the next release of gcc will be signed with this key instead.


Firewall tiered architecture and firewall brands in today's context In the past, we were often taught that we should have at least two layers of firewalls and it was best to use different brands so that at least it would make it more difficult for hackers to penetrate. This is not an issue, but I am mostly seeking comments on such a firewall design in today's context. Firewalls are not the targets anymore, so is it still relevant that we need to have at least two layers and using different brands? Further, the firewalls nowadays come with more features such as application layer protection etc.

I tend to subscribe to the idea of using one layer but placing more emphasis on the configurations and make sure there is 100% no misconfigurations in the firewall rules, plus making full use of the features that comes with next generation firewalls. There is actually no need for two layers?

... Firewalls are not the targets anymore...

Broad claim and I would suggest it is wrong. A single firewall has a strategic position in the network as it is reachable from inside and outside. Thus compromising it from outside gives you full access to the inside. Sounds like an ideal target for me. Having a second firewall which limits attacks from outside to the internal network could definitely help in case the first firewall got compromised. But without the second firewall the attacker has unrestricted access to the internal network.

Apart from that no firewall is foolproof and by combining firewalls you might have a better protection, similar to combining antivirus from different vendors. As a side effect of my research (bypassing firewalls at the HTTP layer) I've noticed that a multi-layered approach can help to reduce the evasion possibilities. But I've also noticed that different vendors often make the same mistakes, which means that multiple layers will not necessarily help to make the protection more robust to evasions.


Exploiting mailto links Supposing that the user has the power to include any content after mailto: snippet, are there any possible security vulnerabilities?

Example:

The user says their email address is foo. The link on the page (which is visible to everyone), will be be: foo.

I'm interested to know if there is a way to exploit this thing.

What if they entered their email as

"><a href="

which (might) be rendered by the application as

"><a href=".

giving rise to a Stored XSS vulnerability.

To prevent this, the application should URL percent encode and then HTML encode the email value.


Mitigate risk of security questions Possible Duplicate:
  Do security questions subvert passwords?

Many Web sites nowadays require a (hopefully strong) password along with some pretty easy security questions. Sometimes it is not possible to avoid filling in the answers. Most of the time, it is not possible to formulate your own questions (e.g., "give me the other random string").

IMHO, this is a hefty security risk for the user. You pick up a secure password (maybe even a truly random one) and let your account open to every one who knows it (e.g. your birthday).

What do people do to mitigate this problem?

Actually, it's worse than that. With the over-sharing that is so common on sites like Facebook and personal blogs, complete strangers can find out all sorts of useful information for hacking security questions.

My best advice is that when you are forced to supply an answer to a trivial question ... lie.

What is your mother's maiden name? McGillicuddy

What was your first car? 1952 Yugo

What city were you born in? Randomville, Wyoming

Actually I was born in the Chicago area and her maiden name was "Smith", and you could find that out fairly easily, but a good lie that you can remember is much better.


How dependable can data encryption be without re-entry of password on startup? I posted a comment awhile back, and thought I would turn it into a question.

Example: There is a feature in the Microsoft SQL Server for full database encryption, which seems to have an option that does not require a password on reboot. I understand you can use DPAPI or EKM, but I am still unsure to the actual limitations of such a system.

I actually am not interested in the Microsoft SQL Server feature specifically, only in the limitations of a theoretical encryption scheme.

Question: Given a server that requires the encryption key to be recreatable without requiring a user to input a secret, How much of a barrier can be placed against the attacker?

I am aware of the following

Complexity (the attacker may not know how to decrypt without looking at my program's code)
User Access barriers (the operating system may be able to store the information in such a way that the user accounts are unable to access without root)

Beyond that, I am lacking any concrete ideas:

If the attacker could read the disk, it seems you would have no protection. (unless maybe you used special encryption hardware)

Finally, for the key to be stored on a different computer, again, I don't see how (assuming Complexity & Security through Obscurity is overcome) you could prevent that different computer from providing the necessary key to the attacker that has access to the server who normally is permitted.

So, any guidance on a typical encryption scheme would be appreciated, and what the limitations would normally be.

The real questions here is: How much of a barrier can be placed against WHAT attacker?  If the system doesn't need a password at boot,  then if an attacker has physical access then it is trivial to bypass.  That is quite literary not a security measure and an attack like the cold boot attack probably isn't required.

So what about MS-SQL?   Well this encryption system is preventing a REMOTE ATTACKER  possibly with a sql injection flaw access to the sensitive data.   Keep in mind if the attacker has a flaw like SQL Injeciton,  then the attacker SHOULD NOT have full access to the disk,  unless of course you have a web app using an unrestricted account like sa,  which would be a much bigger problem.

Moving just the key to another machine doesn't really help, if the compromised machine can access the key, then the attacker can access the key.  What can help is creating a sensitive information store.  So in this model a web application has two databases.  One database for storage of not very sensitive information, and another database just for the storage of encrypted data.   The encrypted database is made to be the most restrictive,  it is only accessed by a white list of machines and the number of queries against this machine is kept to the bare minimum.   The chances of a sql injection flaw against this database is much lower.


Fuzzing with Owasp-Zap I am doing web application testing and mostly performing injections into fields etc. Instead of having to do these manually in each form field how do I go about making this automated against all form fields on a page? I heard this can be done in OWASP-zap but cannot figure out how to do it. Can someone shed some light on this for me?

With ZAP Fuzzing you can specify any number of locations to fuzz in a request.

However if you want to apply specific attacks and know what results you're looking for you might be better off with writing an active scan rule. We have various examples here: https://github.com/zaproxy/community-scripts/tree/master/active


How are private keys stored on disk? I have a public and secret key pair in my .ssh folder. How is the secret key being stored on disk? What I mean is .. Is it possible for someone to hack into my computer, steal the secret key and use it to decrypt all my messages which were encrypted with my public key?

Secondly, gpg requires a password to make use of the secret key. Does it not mean that someone can brute force the password and use the secret key anyways? After all, passwords are never as secure as secret keys ..

Or does the computer do some magic behind the scenes so that brute forcing the password that protects the secret key is simply impossible?

How is the secret key being stored on disk?

Like any other file is stored on disk.

  Is it possible for someone to hack into my computer, steal the secret key and use it to decrypt all my messages which were encrypted with my public key?

Yes. Your private key is VERY important for this reason.

  Does it not mean that someone can brute force the password and use the secret key anyways?

Yes, they can. Using a weak password to protect your private key will not guarantee you much security if your private key should fall into the wrong hands.

When it comes to public/private key cryptography, there is no understating how private your private key should be.


Incentives to Support Adoption of the Cybersecurity Framework The US White House has just release the subject blog post link here which suggests adoption of this proposed new cyber insurance might be rewarded by liability limitations including "reduced tort liability, limited indemnity, higher burdens of proof, or the creation of a Federal legal privilege that preempts State disclosure requirements."

My question is can someone point to cases of such liability and resulting fines etc. in recent history?  My sense is there is little happening in this space thus that incentive will be minor.  I might well be very wrong which would be important to know relative to this possible game changer in 2014.

After Sony's PSN network was hacked, there were many class action lawsuits filed against them all around the world. Some were dismissed by the judge, while others reached an expensive settlement.

For example, this was the result of just one of the many lawsuits:

  Settlement approved in Canadian cyber attack suit

  Class Members who had a credit balance in their PSN or SOE account at the time of the Intrusions but have not used any of their accounts shall receive cash payments for credit balances.
  The Sony Entities will make available online game and service benefits to class members geared principally to the type of account (PSN, Qriocity, and/or SOE) held by the class member at the time of the Intrusions.
  The settlement benefits are available through a simple process. To become entitled to benefits, Class Members need only to complete a claim form.
  The Sony Entities will reimburse any Class Members who can demonstrate that they suffered Actual Identity Theft, as defined in the Settlement Agreement. Class Members that prove Identity Theft can submit claims for reimbursement of out-of-pocket payments (not otherwise reimbursed) for expenses that are incurred as a direct result of the Actual Identity Theft, up to a maximum of $2,500.00 per claim.
  The Sony Entities are to pay for the costs associated with providing notice of the Settlement Agreement and the settlement approval hearing, all administration costs, as well as an agreed amount for plaintiffs’ lawyers’ fees and expenses ($265,000).