SSL certificate appending On my Linux server I have a keystore which contains SSL certificates and these certs are going to expire in 20 days. Before expiry of old certs, I have installed new SSL certificates to avoid any impact after expiry of old certs.

I have below questions.

Would new installed SSL certificates overwrite old SSL certificates which are going to expire? If NO, what is the reason?
It's regarding 1st one. If new SSL certificates don't overwrite old SSL certificates, then how to determine which certificates are working till expiry of old certificates?
If my old certs are from Godaddy and now, newly installed certs are from Thwate, will they overwrite? As their naming convention will be different and may be contents also, I guess.

Yes, they would overwrite the old SSL ceritificates. By overwriting the certificates (both key and actual certificate), you replace the certificates on your website. The visitors visiting your website will not see any error by this.
Right at the moment you replace the key and certificate and restart Apache (or the webserver software you use), it will be replaced for visitors.

I would recommend testing your website against SSLlabs, to check for any errors. Don't forget to check "do not show the results on the boards."


zap proxy - modify post to inject a zip file I am doing a CTF image now, and I need to upload a .zip file to execute using the php wrapper zip://  using this PHP ZIP Wrapper LFI vulnerability

The problem is that the only way to upload is with a POST form, so I would like to intercept the POST, submit and change the text I added for the binary data of the zip file.

I have tried to cat the *.zip file and paste it before continuing the POST but it did not work.

Some people suggested using Burp but I would like to know how to do this with Zap proxy.

Ok well is not exactly what I wanted but in zap if you go to the url with the form.. then intercept and instead of injecting I was able to select the post, then use one of the build in scripts in ZAP to convert to curl and from curl I was able to just add the filename and inject..

Scriptname is:
curl_command_generator.js


Injecting javascript into an alert I have a function like this where json is a json object that is in this form
err: someNumber, and I want to inject javascript into that alert so that maybe i could inject ajax in there or something else, how would I go about doing that?(If it's even possible)

function imageShow(json) {
if (json && 'err' in json && json.err != "" && json.err != "200" && json.err != "OK")
    {
        alert (json.err);
    }
}

For example:

let json.err be { "err" : "<script> alert(\"Hey\");</script> }. and then I could use that alert within the alert.

If not, I have this same function with this
Same json data and same everything, but instead of alerting, it changes a picture's source to the json.err:
Could I inject something into this?

function imageShow(json) {

if (json && 'err' in json && json.err != "" && json.err != "200" && json.err != "OK")
    {
        $("#img")[0].src = json.err;
    }

}

The message in an alert() box is always displayed as plain text. You can't inject code here.
Setting the src of an image to a user-controlled value can't lead to XSS, but some other less severe vulnerabilities as explained in this thread.


How to enable DH_RSA instead of DHE_RSA? I generated DH parameters and set at server side. it always select cipher suite DHE_RSA? Is there any reason that DH parameter have to set server side only.

Ephemeral DH: what is changed P and g every session ? or private key ?

Fixed DH means a DH certificate. Nobody uses this. You want DHE with RSA certificate. Actually, you want ECDHE over NIST P-256 for compatibility and X25519 for security and performance with modern browsers. New versions of Google Chrome don't support DHE.

If you use DHE (which I think your server should support), your server should generate safe params with same bit size as the RSA key in the certificate (generally 2048 bits). With nginx, you should use openssl dhparam command to generate a file and ssl_dhparam nginx configuration statement to point to that file. Other web servers and TLS terminators have different methods of generating safe DH params of appropriate size.


Are there any established secure coding guidelines available for mobile devices? I am looking for secure coding guidelines especially for mobile devices (Android and iOS). The languages I am interested in are Objective-C, JAVA and HTML5.

Would it be a good approach to use a "classic" security framework like the ESAPI for JAVA?

The issues are mostly the same as for secure software development in general.

Note that the most critical issue for secure software development is (1) integrating security into your software development lifecycle (so security is integrated into each step of the process: design, implementation, maintenance, ops), and (2) training of developers.  It is a mistake to think that a software library or framework will magically ensure the security of your systems.

Mobile-specific issues. That said, here are some issues that are worth special attention in the mobile space:

Use secure communication channels.  Be wary of HTTP or other unencrypted communications from the mobile app to servers elsewhere.  Mobile phone users often use open Wifi networks for network connectivity, and those are at high risk for eavesdropping and man-in-the-middle attacks.  Therefore, if you are sending anything confidential or security-critical at all (personal information, session cookies, authentication tokens), you should be using HTTPS, not HTTP.  For custom network protocols, use TLS.

In general, if in doubt, be skeptical of any use of cleartext communications.  Several high-profile apps had vulnerabilities of this form (they sent session tokens over cleartext HTTP); don't make the same mistake.
Store security-critical data securely. If you have a security-critical app, be wary of storing highly sensitive data on the mobile phone.  For instance, you wouldn't want to store online banking passwords or that sort of thing on the mobile phone, and you might want to be careful about things like credit cards -- because if the mobile phone is stolen, that information becomes accessible to the thief.  Theft and physical security are especially relevant, as it is so easy to steal, lose, or borrow a mobile phone.
Be careful about where to store application data. When storing application data, be careful about where you store it and what permissions you use.  You don't want to inadvertently make sensitive information available to others apps.  For instance, on Android, apps can store app-specific data in internal storage, on the SD card, or in a Content Provider.  These have different security implications.  Internal storage is secure by default (no other app can view the data) and is a good standard choice.  The SD card is visible to other apps by default, and thus you need to use more care.  If you store data on the SD card, at least set the file permissions so other apps can't read it, unless the data is intended to be shared.  Content Providers can be protected using Android permissions.
Be respectful of user privacy. Don't do things that will creep your users out, if they find them out.  Be up-front about what you app does.  For instance, don't grab a copy of the user's address book and upload it to your servers (even if you have good intentions, like helping them connect with their friends) without user consent.  Don't upload photos to a server behind the user's back.

One technique, when dealing with unique identifiers like device IDs or email addresses or phone numbers, that sometimes helps is to hash these identifiers before letting them leave the mobile phone.  Don't just upload them to your server.  Instead, hash them together with some app-specific value, then upload the hashes.  In some cases, this can help improve user privacy.
Static analysis. Consider using static analysis tools that know about mobile-specific risks.  For commercial tools, Fortify has a good reputation for this.  For free tools, Comdroid and Stowaway check for a few risks that are specific to Android applications.  However, beware that the free tools are not as comprehensive or polished as commercial offerings like Fortify.

Know your platform. Educate yourself about security risks specific to your particular mobile platform.  For instance:

On Android, watch out for Webview related vulnerabilities.  If you use webviews in your application, and you expose any of your application via the Javascript interface (e.g., webview.addJavascriptInterface(), webview.setWebViewClient()), then there are subtle security risks.
On Android, watch out for Intent-related vulnerabilities. Android Intents are great; they allow for flexible cross-application communication.  However, they also introduce new security risks.  In particular, they share many of the potential risks of other communication channels: eavesdropping, spoofing, and man-in-the-middle attacks.

To avoid these problems, you know the risks.  When using Intents for communications internal to your app, use only explicit intents (not implicit intents), and make sure all your intent receivers are internal only and are not exported to the world (beware that under some circumstances, Android will implicitly export components; you want to avoid that for ones which might receive your internal intents).  When using Intents for cross-application communication, beware that Intents can be injected and eavesdropped if you are not careful.  Therefore, when receiving an Intent that may have come from another application, treat its contents as untrusted and apply proper input validation/sanitization; you may want to check the sender of each Intent you receive, too.  When sending implicit Intents that could be received by other apps, beware that they can be intercepted by malicious apps, so you should avoid including any sensitive or confidential information in the Intent.  Avoid mixing internal communications with external communications.

For an introduction to Intent-related vulnerabilities, read here and here.  More technical details can be found in the technical paper.
On Android, avoid permission re-delegation attacks. A permission re-delegation vulnerability is one where your app has a permission P, and is willing to respond to requests from other apps by performing operations that require permission P.  If the other apps don't have permission P, you've just leaked the privileges associated with P to those other apps.
On Android, beware SQL injection vulnerabilities. On Android, Content Providers can be accessed through SQL queries.  You'll want to avoid classic SQL injection vulnerabilities.  In addition, if you build your own Content Provider and implement your own methods (like delete, execSQL, rawQuery, update, updateWithNoConflict) to handle queries on the Content Provider, be careful when implementing those methods to avoid inadvertently introducing SQL injection vulnerabilities -- experience has shown that developers often introduce problems when implementing those methods.  The best way to avoid these problems is the same as on non-mobile platforms: use parametrized queries (prepared statements).

Other resources.  For Android, I highly recommend the following presentation:

Seven Ways to Hang Yourself with Google Android (slides)

For mobile security in general, I also recommend looking through the following questions:

Android API/development security pitfalls
Secure Software Development
Vulnerabilities common only in mobile solutions?
Top Mobile Device Security Concerns?
Any useful tools for Android source code review?
Do mobile OS's provide crypto-quality randomness?


In Login page of web application, I have allowed drag and drop of any text. Is it vulnerable to XSS attack? Will I need to add any attribute to restrict drag and drop of any file?

An XSS attack is performed by injecting malicious code to be displayed to another user.

To use a standard login form for an XSS attack, you would need the malicious code to be in the username - the only thing likely to be shown to other users.
But how the username-with-malicious payload got in there isn't relevant, so it is not inherent to the fact that you use drag-and-drop.

Allowing a username that consists of a large amount of text (for example, the contents of a file) would make it easier to perform this type of XSS attack in a username. So you'll want to check the username against it.

That being said, usernames are often limited in the length they're allowed to have. This makes them unlikely attack vectors. If you're running some kind of forum, users signature lines and forum posts are more likely places to contain an XSS attack.


Feeding Azure portal logs into a SIEM solution Currently working on a cloud transformation project where all infrastructure is being placed into Azure.

We currently use a SIEM solution to monitor and assess events across the environment. The adoption of Azure has added an additional level of administrative actions that we would need to keep an eye on.

Our design uses AD groups that are assigned to RBAC roles and so we can monitor changes to these groups in order to understand who has had access granted/revoked by collecting our DC logs. We cannot however see if someone has granted/revoked RBAC roles to Azure subscriptions, resource groups or resources. I have put together some Powershell scripts that would return the required data so it's good to know the data is there and available, however it seems that there is no native way to get this data into a SIEM solution.

Has anyone managed to get this type of data into their SIEM? I envisage it being achieved by having a Powershell script running every minute or so to retrieve the data and either writing it to a file which the SIEM collects or streaming it directly to the SIEM to then be parsed.

Essentially, I aim to get something in place so that I can view this data within our SIEM dashboard as I feel it's a significant risk to have no visibility of such administrative actions.

Thanks in advance for any guidance.

As part of the Security Center GA announcement MS introduced the preview of a log integration connector for SIEM integration.  I haven't tried it out myself yet, but I imagine this will be the new recommended solution for your request.


known public exploits for vsftpd 2.0.1/2.0.5 I somehow noticed that there were numerous reports of security vulnerabilities of vsftpd 2.0.1~2.0.5; however, there just seems to be no public exploits.

The server I am working on has vsftpd 2.0.5 (set up by my supervisor-head administrator), and I am just worried that someone might be able to attack the server...

If there is any known exploit, can anyone provide me with the known links to public exploits? (so that I may make some vulnerability assessment.)

Exploit-db finds 3 exploits (click link). 1 for that specific version and 2 for higher versions.

OSVDB shows 11 exploits however you have to click each ID to see which version the exploits are for.

cve.mitre.org also reports 11 exploits. Versions are listed in the description. There are some there specific for 2.0.5.


Occurence of ROP gadget I'm researching various buffer overflow techniques, one I encounter and is pretty interested in the moment is Return Oriented Programming (ROP), and the use of small groups of instructions known as gadgets.

The question: There are certain gadgets that are popular and used extensively in many exploits, for example the POP/POP/RET sequence. Is there any research or proof that occurence of such a gadget or its equivalences is high enough that always there will be one in most binaries? I'm looking for a certain common library or a popular compiling techniques that will produce these sequence.

EDIT: In short, will POP/POP/RET and equivalences will always be in a binary?

I'm asking in the x86 context, but if there is any other lead in other platform, do share.

Creating a ROP chain is a difficult, creative, laborious yet exciting process. Generally speaking, when we are using ROP, we are trying to bypass DEP. After all, if we have control of EIP and can write to and execute the stack, why not just jump to our shellcode?

With that in mind, it is important to remember that entire payloads are not, generally, written as a ROP chain. Spawning a reverse shell entirely out of ROP gadgets while certainly possible, is likely to test the sanity of any exploit writer.

The function of a ROP chain is merely to deactivate DEP. We use ROP to turn off DEP (by adding the execute permission to the memory page that holds the stack) and then simply jump to our traditional shellcode payload.

On Windows, this is usually a case of making a VirtualProtect() system call, loaded with the correct parameters to allow execution of the stack. It has been shown that kernel32.dll alone contains appropriate gadgets for making such a call in most cases. Tools for identifying potentially useful gadgets in program code can make this process much easier. See this page for a detailed example of the process.

So whether or not a specific sequence, such as POP POP RET is present, is not all that relevant. In any program that links major libraries (which they all do), there will be more than enough gadgets to build a simple DEP deactivating ROP chain. All it takes it a bit of lateral thinking - it's like trying to build a jigsaw puzzle when every piece comes from a different box.


How can I use OpenSSL with an external source of randomness? When generating RSA keys using OpenSSL, if I want to use an external source of randomness (e.g an HSM that can provide random numbers), is the best way to get a new random number (for every generation), dump it to a file, and then use that file in the OpenSSL command line with -rand?

Is it necessary to balloon that file with several kBs of random numbers?

OpenSSL will use /dev/random if available. And: that is an excellent source of entropy, especially when used with a hardware source of entropy. I'd recommend you watch the excellent lecture held at 32c3 on misunderstandings and reality of /dev/random:

So: Use your hardware generator to feed your operating system's entropy pool, and let OpenSSL feed off that. Directly feeding OpenSSL from your hardware might work, but is not really any better – and more importantly, you eliminate the intermediate step of dumping randomness to a file, which might leave traces that could later on be used to reconstruct key generation.


Trusted Platform Module, daughterboard vs onboard TPM? In many cases where a Trusted Platform Module (TPM chip) is employed, it is soldered directly onto the motherboard. Ostensibly the motherboard manufacturer is then solely responsible for integrating the BIOS and TPM module, and the overall tamper resistance of the solution.

TPM modules are also available as add-on daughter cards, which plug in to a small 19-pin connector on the motherboard.

From a security perspective, is one solution clearly better or worse than the other? Is there specific functionality one should look for in the BIOS or the TPM module when a daughtercard TPM is used?

A daughter card normally implies it is using a LPC (Low Pin Count) bus. This bus is slow and can relatively easily be monitored/manipulated. This is the basis of the famous TPM reset attack on version 1.1.

1.2 introduced the concept of Locality which mitigate this issue but is said to not entirely prevent it (not proven) - the window of attack is way smaller but the communication is not authenticated.

Not all TPMs are made equal and you get to choose your level of security. While a daughter card would likely not mitigate against the physical reset attack, a lot of new TPMs are integrated within the chipset - since 2009 if I recall. Intel provide those TPMs as part of their vPro technology. They run has application within the Management Engine in the Platform Controller Hub on new architecture or northbridge otherwise. In turn, it means the attack surface is most probably null.


Why would someone register a Facebook account with a stolen email address? I witnessed an interesting attack today. Someone was able to register a new Facebook account with the email address of a friend of mine. We don't know how it happened, because Facebook requires you to click on a confirmation link to use an email address. Maybe the attacker got access to the mailbox somehow.

The interesting question for me is, why would someone do this? It is easy to create a free email address within minutes. Why does the attacker use the email address of someone else? It is no impersonation scenario, because the Facebook account has a totally different name than my friend. I cannot think of a reasonable scenario that makes stealing an email address for creating a Facebook account worth the effort. Am I missing something?

Update: First of all, no one from Facebook responded to our abuse message. Nevertheless the fake account was gone after several days - we have no idea if Facebook took active measures against this account or not.

I didn't think about the obvious counter measure against this fake account when the incident happened but this idea might be interesting to others facing a similar problem. If someone registers an account with your email address, there's nothing easier than resetting the password of this account and access/delete it - you are the owner of the email address bound to the account and the "lost password" function plays into your hands. I am not sure if this would be 100% legal though - depends on the question if the account is actually yours, if your email address is bound to it.

Two possible scenarios that pop into my mind:

Since we can assume the attacker probably had access to his email, he probably had access to his address-book as well and he could have requested friendship (search for friends by email address) from all the people that had a facebook account registered to one of the email addresses from that address-book (some of those requests would succeed). Despite having a different name (lots of people don't use their real names on facebook), lots of people would accept the invite either blindly or since they would see they had friends in common (the ones that accepted blindly). After that, he would have access to additional data about all that other people, etc..
He could just let the facebook account lay there and wait for someone else to find him by searching friends by email after which, he would again have access to additional data.


What can be done against DDoS attacks when I just have only small number of "known" clients reaching a server? Description of the Situation:

Let's say 1000 "known" clients/workers are collecting time-sensitive data from the field and sending to a server. Therefore, we need to secure the server from DDoS attacks at a specific day and period of nearly 3 hours. It is expected to have DDoS attack during this process.

Question:
What are the possible ways of securing this process for that critical period of time?
Maybe load balancing + firewall for allowing only 1000 "known" IP addresses ... etc?

I would whitelist in the Firewall the known IPs (it can be done in minutes if you already have the IPs even if they are 1000). That would make sure anything else trying to connect will be automatically rejected.

In a CISCO firewall this certainly would work fine. An ASA if with a Content Security and Control Security Service module then you may enable signatures as well to mitigate DOS/DDOS/SYN-FLOOD.

Additionally, in the case of a Linux machine, you could just enable fail2ban and get rid of anything unwanted.

In the good case scenario, your server is behind a Firewall and you put filters on both the firewall and server machine.


VPN over HTTPs for a web service only I have a web service (PHP & MySQL on Ubuntu 12.04) running in a corporate intranet. I have also connected it to internet through a firewall letting incoming connections on HTTPs only (port 443). I'm considering now to add VPN over it to add additional security level, to open VPN ports and close HTTPs. That seems to be more secure but more inconvinient for an end user too. Users will be loginging from ther PCs, tablets and phones using a VPN client to access the web service and the their login and password to access their data.

As I understand it adds additional login/password pair to the authentication process and basically that is the only advantage. Of course such a set up adds IPSec encryption but I don't think VPN encryption is a useful feature here as the traffic already encrypted with HTTPs.

In a VPN case a malicious user would scan a server for open ports, find the VPN ports open and start to brute force VPN user access credentials before he can start to brute-force/code inject the actual web service.

But if I would just need another login/password pair I can just make a double-step authentication process on the web service instead of bothering users with a VPN client set up.

So it seems like a VPN pros in my case are:
Additional authentication step using a VPN client
IPSec encryption
Everybody think you are safe

VPN cons are:
Additional authentication step which adds complexity for the users
Useless encryption of already encrypted HTTPs traffic
VPN user get access not only to the web service but to the entire sub network so extra equipment needed to put the server to DMZ.

Am I wrong on any of those points? Would a VPN really add more security in my case or it will give more unnecessary complexities instead without really adding anything useful?

It's a tradeoff.  You're probably better off behind the VPN, but at a cost.

VPN will add a 2nd layer of authentication
VPN prevents unauthenticated attackers from attacking web app
VPN increases support burden
IPSec VPN doesn't traverse NAT well
VPN potentially makes things slower

Your webserver should already be in a DMZ.  Exposing a service to the internet that's on an internal (non-DMZ) network is a significant risk.

If you have users authenticate to the VPN, you should try to use some sort of single-sign-on solution so they don't have to authenticate to the app as well.  The idea of adding 2 sets of usernames/passwords to the app is just cruel to your users, and would offer very little security benefit (might actually encourage the use of weaker passwords, increases attack surface).


What techniques do web services use to identify password theft? I've noticed that some web services use a security scheme in which log-in attempts that have some unusual characteristics trigger extra authentication steps.

For example when I try to login to my Gmail account when I'm abroad it sometimes makes me solve a captcha, or asks me what is the location I usually log-in from.
Another interesting example is when I try to log-in to my Facebook account from abroad, and it shows me pictures of my friends and asks me to identify them before I am granted access to my account.

I assume these measures are taken to protect my account from password theft.

What criteria do web services use to find suspicious activity?

One answer that is obviously derived from the examples above is a log-in attempt from a different country than the one the user usually logs-in from. I'm curious if there are any other techniques, perhaps even ones that are used not only during authentication, but during the rest of the user's activity on the site.

Is there any information available on what techniques various web services are currently using?

In addition to the verification methods you've provided, Web services keep track of users using the following methods. Usually a failure in any of these services can cause a site to block access or lock an account.

Cookies

These are text files that a website will send to your browser when you access a site or service. These files contain information specified by the site for use in things like authentication and recognition. Sometimes they store preferences, other times they may store things like last access time or last IP address. Often this information can be encrypted or encoded in a non-readable method. When a user visits a site, the information on the computer (if it exists) is compared with what they have on file.

Cookies are also useful in catching failed attempts. When a person (UserB) tries to login to a site as UserA the site can present them with a cookie for the username they're trying to use and another one containing the number of logins they've attempted. When they login as UserB and use their own account at a later time, the site can collect the cookies for the previous attempts and then cross-check their records to see if UserA is related to them or aware of the attempt.

Sessions

When a user accesses a web server they open something called a session. During the session, the browser and the server exchange information in the form of variables and cookies. This information will exist as long as the session is open. Sessions can have a specific timeframe where they are active and they can also be destroyed when someone leaves a website or closes their browser. When a person tries to access a site from a second device using the same logins this will open a new session. Some websites are aware of this and will say something like "You're accessing your site from two locations. If you are NOT accessing this site from multiple locations please contact customer service."

Database Comparison (Location, Device, Activity, Habits)

Some web applications store information about a user, their habits in terms of spending (banks and credit card companies do this), frequency in access, and IP geolocation. When a user accesses a site their stored profile is compared with their current session to see if the user's behavior fits the pattern on record (Location, Device, Duration of access, Etc). An example might be someone logging in from another location where they have never logged in before.

Two-Step Authentication or Verification

Some sites like Google may require you to use an authentication app installed on a mobile device that you have been previously authenticated on or they may require you to check your e-mail account to get a one-time password. This is called two-step or two-stage authentication or verification. When you attempt to log into the site from a new machine or a machine that doesn't have an active session or existing cookie, you'll have to provide information from the second device (usually a cell phone or e-mail) to prove that you are the person who originally setup the account. Sometimes this is also done in the form of an SMS text message.

Timers and Real User Verification

Some sites will use a real user verification scheme like a CAPTCHA to make sure that a user is really a person and not a bot. Websites like banks and some stock photography sites implement other schemes to make sure you're not performing too many tasks at once when you have your session open. If you're reacting more quickly than a human user they may close your session. Additionally they may close your session due to inactivity because they try not to assume that a delay in access means the same user on the same terminal.

Preshared Key Verification

Most websites will provide a user with a password. The user is requested to provide this password when they access the site again.

Challenge and Response

Some sites request information in addition to a password in the form of a challenge and response phrase where a user can authenticate themselves. "Where do you go to School?" "Where were you born?" the answers to these sort of questions are typically not known outside of a user's circle of friends and family. The reason these questions aren't the main questions for authentication are because of things like unfiltered social media where someone can do a web search and find the answers by reading a profile.


Security concerns about purchased PHP script (web app) I have been thinking about buying a ready-made PHP script (i.e. a web application) that provides a specific functionality. Say, for example one of these sold by Agriya:

http://www.agriya.com/products

The concern I have about these is, how to evaluate the security of this type of script. Not only is there a concern about whether "lousy programming" may have introduced bugs but also if some back-door has been intentionally added by the vendor.

Mainly my concern is around payment safety, as the website would be accepting payments through either credit card or PayPal.

Is the only option to just "not buy it if I cannot trust the software vendor", or are there some things that can be done (specific questions to ask, things to check for, etc) to minimize the risks? Is it expensive to have this type of scripts checked by some third party?

Unless the company tells you that they have been audited by some security company (and depending on the company that assessed it), you will never know until you take a look for yourself.

Trust is a complicate thing... It is hard to gain and very easy to be left along the way.

One think that you may do is talk to Agriya and tell them that you're interested in their products, but wary about the secure development practices employed by them. Ask them if they have made a thorough security assessment in the softwares and if the answer is "No", ask them what would they do if anyone finds bugs in it.

@jeroen-it-nerdbox raised an important issue. These things might cripple your business and a strong AND fast correction process is of vital importance for you and their customers.

About the price of a security assessment in the code, it depends on the company doing the audit. My department does not have ties with the commercial area of the company, so i cannot help you with that.


What sort of security method is this called (if it has a name)? I have thought of a way of securing access to an application interacting with another application.

Using this method

Application 1 - "What is the sum of 1+1?"

Application 2 - "3"

Application 1 - "Access granted"

Is this method used a lot, does it have a classification in the programming world?

The advantages for me of using this is that I do not have to spend more effort implementing security keys/certificates.

Any unauthorized machine trying to interpret it would give the correct result and identify itself as untrusted.

What sort of weaknesses are there to doing this?

Edit 2: Since this has been migrated to Security.SE, I should probably preface this with with: I'm not a professional cryptographer, and there are many, many reasons why you should never roll your own security.  Having said that:

It's a form of challenge-response authentication (with different challenges being sent each time).  The algorithm to find the correct answer is essentially the "secret" or "password".  You are open to a number of attacks, but essentially, anyone who can figure out your algorithm can break this security, and it is relatively trivial to reverse engineer executables.

Edit:  To put this into perspective, consider Wikipedia's summary of Kerckhoffs's principle and Shannon's maxim:

  In designing security systems, it is wise to assume that the details of the cryptographic algorithm are already available to the attacker. This principle is known as Kerckhoffs' principle — "only secrecy of the key provides security", or, reformulated as Shannon's maxim, "the enemy knows the system".

In your case, you've come up with a secret algorithm, but have no real "key" (there is no shared secret between the two endpoints, other than the algorithm).  Once someone figures out the algorithm, the security is broken; so at best you've raised the bar slightly for people trying to figure it out.  Rest assured though that anyone who really wants to break it, will do so.  In that situation, you've also got a difficult problem of having to replace the compromised algorithm (as opposed to simply switching out the compromised key).

There's a reason why modern cryptography prefers large keys over complex algorithms - no matter how complex the algorithm is, it can (and will be) reverse engineered.


Penetration testing - how to fix a vulnerability? Welcome, I always wanted to ask this, how you fix/patch a vulnerability by yourself? /maybe possible duplicate, but I have not find the same, or I search the wrong way.. (sorry) /

I know a bit how to test a web_app vulnerability,and I understand how to fix them.
But let's say there's a vulnerable operation_system and I want to patch the vulnerabilities by myself and not by security updates from devs?

Or it's affect if the OS/App is open-source or closed-source? /my rights to solve the mistake in the source code../

Thank you for educational informations, we need to learn to learn something. :)

When the application is open source, then you just need to find the sourcecode section which is responsible, fix the bug and recompile. You might want to send a patch to the maintainers of the application so they can apply it to the mainline.

When the application is closed source, then providing a patch yourself is usually practically impossible. You could do what the crackers do and manually edit the compiled binary with a hex editor, but this is 1. very difficult and tedious and 2. often a violation of the EULA of the software.

Sometimes you can plug a vulnerability temporarily with a firewall rule or some other middleware layer which prevents the exploitive data from reaching the application intact. Sometimes you can also temporarily fix a vulnerability by switching off a specific feature or changing a specific setting of the application (hope it's something you don't need).


Screenshots and steganography, can malicious code in image be copied? If you have an image that has malicious code written into it using steganography would a screenshot of that image have functional malicious code as well? Or does the recapture transform the image data enough to scramble anything that was previously arranged?

That depends entirely on the kinds of steganography used
For example, you could modify the least significant bit of every pixel to store data in it. This has a visible, although barely noticable effect on the image. It requires the file to be transmitted as is, as even slight changes in the colour values of the image will destory the associated information.
If you make a screenshot and that screenshot is a perfect, pixed-by-pixel replica of the original image, that screenshot will also contain that information, although it will be much more difficult to extract, since it will also contain a lot of irrelevant data.
It's also possible that the program you use to make that screenshot compresses the data in a lossy format. As such, if you have a large white background - as you do on a document, for example - tiny variations in color - as you would have when hiding information via the LSB method - would be "smoothed" over and stored as one blob of colour, thus effectively destroying the information.
Other methods of steganography rely on the way a file is structured to hide the information. As such, methods that copy the visual information will not copy the hidden information.
Summary
Is it possible? Yes. Always? No.


File signature vs Virus signature I have thought of creating simple anti-virus. I have read some article and they said that the there is a two way of detection.

The virus dictionary signature searching is the one method. So I have chosen this method for the simple implementation.

From this, I have understood that we have to search the virus signature with the file.

What is the difference between file signature and virus signature?

If I have saved a virus file where the virus signature will be stored in the file.

How to match the virus signature pattern with the file signature?

If there is any sample code to explain, would be better for me to understand.

Some virus signatures links. How to write code for this signatures?
http://www.nlnetlabs.nl/downloads/antivirus/antivirus/virussignatures.strings

http://codes-sources.commentcamarche.net/source/21418-antivirus-2004

http://www.clamav.net/

There is no such thing as a virus signature stored in the file. Creating the signature of a virus is a process which is using various properties of the malicious file to get the signature value. In the easiest case this might just be some hash like MD5 of the file. But one can also have more intelligent signatures which for example skip parts of the file which are irrelevant for the functionality of the virus or include structured information of the PE header or similar into the signature. How the signature of a virus file gets computed depends on the intelligence on the AV engine and is usually proprietary information.

As for the file signature: There are various forms of file signatures but in the context of AV it is probably computing the signature of an unknown file the same way as computing the signature of a malicious file and then checking if the file signature matches any of the known signatures for malicious files. If this is the case the unknown file is probably malicious too. But how certain this information is depends on how the signature was computed.


Is there a known vetted alternative to this key-exchange protocol? I have three participants:

A client A in possession of the public key Kpub
A login server S in possession of the private key Kpriv
Game servers B (B1, B2 etc)
S and all B may share a finite number of secrets before, but not after the exchange. This is basically a scalability measure. If S would need to send data to B in order to create a key for A, then that makes scalability harder.
A and B should not use asymmetric key exchange, to reduce CPU impact on game servers.

The current scheme works roughly like this:

Client A, Login Server S, Game Server B

(1) A → S : { Na, A }Kpub

Ksa ← { Na, Ns, A, Saltenc }PBKDF2

Ksasign ← { Na, Ns, A, Saltsign }PBKDF2

M ← IV || HMAC(IV, { Na, A, Ttimestamp }Ksb)Ksbsign || { Na, A, Ttimestamp }Ksb

(2) S ➝ A : { Ns, IV, HMAC(IV, { Ns, M }Ksa)Ksasign, { Ns, M }Ksa }

(3) A ➝ B : { N'a, M }

(4) B ➝ A : { Nb }

Kab ← { Na, N'a Nb, Saltenc }PBKDF2

Kabsign ← { Na, N'a Nb, Saltsign }PBKDF2

Encryption proceeds using Kab, signing each with Kabsign and keeping a running counter with each packet.

I'm aware of some weaknesses in this as it is written which I intend to fix, but you should get the general idea of what I'm doing:

Client A requests an encrypted packet containing it's nonce Na securely from S.
S returns the packet encrypted packet in a way that A can assure the packet is from S.
Client A gives the packet in the clear to B (since no one but B or S can decrypt it), who unpacks the nonce and can create a shared key Kab. This shared key is then used for the remaining communication, such as authenticating or registering A. (Of course, there are nonces thrown in, so each new request for a Kab will produce new keys)

So this is basically just for ensuring confidentiality of the channel between A and B.

The nice thing is that if the connection is dropped or logged out, then A can  use M again for new connections to B without keys being repeated.

Now, given the difficulty getting a protocol right, it would be awesome to use a well-known vetted protocol for this.

Does anyone know of an alternative that works in a similar manner that I could replace it with?

EDIT:

The aim here is exchange keys in order to set up a secure channel between A and B. This is because at this point A might not be registered at B, so will need a way to register securely without anyone eavesdropping on that registration.

This is why the Kerberos model doesn't work - A might be entirely unknown to S and B.

I'm seeing the following possible threats I want to avoid:

Someone eavesdrops on A's registration and is then able to login as A.
Someone eavesdrops on A's login and is then able to play as A.
Someone eavesdrops on A's login and is able to login as A by replaying the first messages. This will cause A to get disconnected even if the attacker can't continue the conversation.
If, due to network issues, many clients simultaneously disconnect and then reconnect, the reconnect is sufficiently costly that B is unable to process all connects.
Someone mounts a man-in-the-middle attack and is able to randomly change what A does.
Someone redirects traffic to a server B' without A being aware of it.
A DDoS acting like (4) should only affect the server attacked.

Or more succinctly:

A can safely play - any covert manipulation will be detected by client and/or server and no-one can steal A's credentials without accessing the data in the client directly.
The server topology is not sensitive to DoS / DDoS.

I can't understand what your requirements are -- strangely, you don't seem to have listed the security requirements, or threat model, or what you are trying to achieve -- but the obvious approach would be to use a Kerberos-like (Needham-Schroeder-style) protocol. Those schemes give S a way to help A and B establish a secure channel between them. They can be implemented using just symmetric-key cryptography, so they should perform and scale extremely well.

In straightforward Needham-Schroeder, we assume that initially S and A share a symmetric key (KS,A) known only to them, and that S and B share a symmetric key (KS,B) known only to them. After execution of the protocol, A and B receive a session key (KA,B) that's known only to them, and that A and B can use to communicate securely (to establish a secure channel between them). Both A and B receive assurances of each other's identity. The Needham-Schroeder protocol has been well-studied; for instance, early versions had a subtle flaw, which was subsequently discovered and corrected in later research by Gavin Lowe.

If there is some reason why the server needs to authenticate itself using public-key cryptography, Needham-Schroeder can probably be modified in a straightforward way to support that. (For instance, A could connect to S using TLS or something similar; then S could continue from there to help A and B establish a secure session key KA,B, by sending KA,B to A, and also giving A an encrypted version of the session key, encrypted in such a way that B can decrypt it and verify its freshness.)


Cracking RSA keys, only given N and e Is it possible to crack RSA keys when only given N and e? If so, is there a limit to how long N or e can be? How do you go about doing that?

In the specific scenario I'm researching, N is about 150 digits and e is about 5 digits. I also have C, but not M.

A 512-bit key has about 154 decimal digits, so that should be the size your facing. This should cost less than $100 to factor.

  The Factoring as a Service project is designed to allow anyone to factor 512-bit integers in as little as four hours using the Amazon EC2 platform for less than $100, with minimal setup.

See Is 512-bit RSA still safe for signature generation? for helpful links including how-tos and readily made scripts for running factoring on AWS.

There is also a good chance that the programmer messed up something, for example by using textbook RSA or providing a decryption oracle (if you have access to a server which can decrypt messages). But I'd only invest time in this if you either have the source code (so you can see which mistakes they made at a glance) or if it's a CTF (where you might be expected to exploit such a mistake).


How to encrypt a password stored in a database (need to decrypt later) I am working on a system that can connect to any number of different systems. Someone inputs the credentials for a system to connect to, and my system remembers the credentials and uses them to authenticate and communicate with it at a later date (which will happen without user interaction).

All of the other questions like this have the answer "hash hash hash!", but you can see hashing won't work for me as I need to decrypt the password later to connect to the other systems (which are agnostic of mine).

Right now I'm thinking I should dynamically generate a random key for each new system and store it on disk, then store the password (encrypted with a symmetric algorithm) in the database. That way the info in the database alone isn't enough to decrypt the key.

Is that the best I can do?

You are correct if the system you are connecting to can accept nothing but a password as a credential. If this is how the remote system works, it is unfortunately designed, and should be extended if possible to accept some other kind of token. Examples of more appropriate tokens are Kerberos tickets, SSH keys, OpenID credentials, or other custom per-application credentials.

All of the good authentication solutions have something in common: They allow the user to authorize you to connect on their behalf, without having to give you their credentials. A good system allows my administrative assistant to buy airplane tickets on my behalf. It doesn't require my admin to impersonate me.

If however, the remote systems are poorly designed and cannot accept this kind of delegated credential, then you have no choice but to store the passwords. It is traditional in that case to obfuscate the password in your database using some kind of "encryption key and algorithm." (For example, AES encrypting the passwords against a key stored on disk.) This should not be confused with real encryption; it is only obfuscation. But it can be useful obfuscation if you have no other choices.

A better solution than a single password stored on disk is a hardware key that performs the decryption for you. Such a device is often called a Hardware Security Module and often takes the form of a smartcard (sometimes it's a full rack-mounted device, a board, or a USB key). You present the encrypted password to the HSM, and it hands you back the unencrypted password. The advantage of this approach is that if someone clones your disk, they still cannot decrypt the passwords. HSMs are difficult to physically clone, making it much harder for an attacker to steal the credentials without being detected. In the best designs, the process that talks to the HSM has a credential that is hand-entered at boot and is only stored in memory. So random processes cannot query the HSM, and if the machine is unplugged it can no longer access the passwords. Even in this scenario, it is possible that the attacker might trick the system into decrypting all the passwords for him, but the attack surface is greatly diminished.


Applying regexp for user input validation using JavaScript As a full-stack developer I am buliding an webapp for tennis club in codeignitor framework. During making html forms on client side and writing scripts for validation of user input.  i thought would it be good idea to use regexp to secured my webapp from sql injection and cross site scripting (xss)and to validate your user input data. So my question is:
      - should i consider my webapp safe from sql injection, cross-site scripting and some malicious methodology.?
      - or there othere ways to safe and secured your webapp?

You shouldn't be relying on regular expressions to prevent SQL injection or XSS

SQL injection is prevented using prepared statements

XSS is prevented using the corresponding encoding for the context where the input value is used, f.e. if you're inside html tags like <p>{{user_input}}</p> it should be encoded using html entities


Is this foreign call some kind of scam and what kind is it? Every few days I get a call on my mobile phone from a number like 370 621 65748, which seems to be a Lithuanian number, but it only rings once and then disconnects. It happens enough to seem intentional, but since they don't even wait until I answer, it's not clear what possible gain could be had.

Is this a known scam or attack vector? Could they be calling numbers at random and probing for vulnerability in some way even without me answering?

If you look up that number on Google you will see that people complain that the phone only rings once, so that single ring does not happen only by chance. You can find complaints posted months or years ago, so it's not a new type of scam. And if you google "phone scam one ring" you will find lots of results, because apparently this scam has also been in the news recently. Here's a couple of links, and one is from the FCC (Federal Communications Commission) that apparently issued a warning on May 3rd:

https://www.fcc.gov/consumers/guides/one-ring-phone-scam
https://gizmodo.com/beware-the-one-ring-robocall-scam-1834578615

It's all about getting you to call back. You see the missed call, you call back, and you end up paying a lot of money because of a special toll or a call to a foreign country. Apparently the scammers have a way to get a percentage of what you end up paying in the bill, or this wouldn't make sense.


Why is /dev/random so slow on Linux? If it's true you only need about 128 bits of entropy to fuel enough data forever, why is it that /dev/random is so slow?  My system has uptime of 214 days!

Is it really only gathering .000000001 bits of entropy every sample?  Shouldn't a mere jitter reading from the kernel provide at least 1 bit of entropy?  Hasn't it been sampling for the last 214 days?

Is this a colossal design mistake or am I missing something?

BTW, I consider this to be more of question of IT security or Linux operating system than cryptography.

A problem with Linux's /dev/urandom is that it is not possible to test if it has been properly seeded. The random number generator may return values which are based on insufficient entropy.

Thus, many turn to /dev/random instead. However, there are significant differences between /dev/random implementations on different POSIX compliant (or clone) systems. On FreeBSD, /dev/random is works the same than /dev/urandom on Linux.
Mac OS X is similar to FreeBSD in many things and also here: /dev/random is just like /dev/urandom.

The goal of Linux /dev/random is to basically return full entropy (one output bit contains one bit of entropy). The approach to this goal is to estimate amount of entropy collected and use that estimate and collected entropy material to produce output. Without Linux support hw-based entropy sources available, the basic entropy collection mechanisms will gather entropy quite slowly.

There are a few ways to accelerate entropy collection, including:

Use HW entropy sources (e.g. /dev/hwrng), these require e.g. "rngd" program
Type characters with keyboards
Move mouse (under X Windows)

If the /dev/random is empty after long uptime of the machine it means that some applications have been using the randomness devices. In Linux, /dev/random considers that the same amount of entropy is lost from entropy pool than was total amount of bits requested. (I.e. even if linux has full 4096 bits in entropy pool, it still wont take very many requests of say 128 or 256 bits to deplete the pool). Occasionally pool is depleted because some application misuses /dev/random. Some applications may attempt to read large amounts of data, like 2048 bits from it.

Long story short, you should read appropriate man page (man 4 random), and decide if /dev/random or /dev/urandom is actually what you need. If the mac's /dev/random would be ok for you, chances are you would be happy with /dev/urandom. The reason random number generation appeared from /dev/random much faster on Mac is that on Mac /dev/random means something different than /dev/random on Linux. Last, but not least, I would want to say: I like the fact that Linux offers two different semantics, operating systems where /dev/urandom and /dev/random are the same offer much less choice.

I would say this is not colossal mistake, the design is just bit odd from perspective of many. Once you are familiar with the design and restrictions and know how to use the devices, the design feels fairly good.

(BTW, other systems like NetBSD still have little bit different semantics for /dev/random and /dev/urandom.)


Is Certificate-Based Authentication Really Better Than Password Authentication in OpenSSH? I recently set myself up with a VPS and have been hardening it to the greatest extent of my limited knowledge!

I was configuring OpenSSH to use certificate based authentication when something did not sit well with me. This could well be down to me missing a configuration option along the way, but if not, it is surely quite concerning:

When adding a key to the remote host, I used something resembling ssh-copy-id username@remote-host to copy it there. When doing this, it prompted me for the password for username@remote-host, which I duly provided.

When I went in to work the next day, I did the same from a machine in work, just to act as a failsafe and then turned off password authentication. However, from a third machine, I was still able to upload a key while only needing to know the username and password.

If this is how it works, surely an attacker will only need to compromise the password, even if cert based authentication is enabled - thus negating its use?!

I have to be missing something, right?

(Don't worry, I have two factor set up on my VPS using Google Authenticator now!)

Ensure that /etc/sshd_config contains the following line:

PasswordAuthentication no

You likely have that line commented out, which allows you to fall back to password authentication. Be sure to restart sshd after you change your config.

If you want to install a key from a new computer, you can temporarily comment out that line, install your key after authenticating by password, and then re-disable password authentication.

I also recommend disabling root login:

PermitRootLogin no

(If you only allow public-key authentication, this won't matter as much if the root user doesn't have an ~/.ssh/authorized_keys file, but it is still good to have in case you change your config later.)


Protect key-streched hashes from rainbow tables? I have a database table with accounts. I'm using PBKDF2 to create hashes from passwords. The passwords are of the correcthorsebatterystaple type, so we assume they are secure and unique. There are no usernames, so I need to be able to find the matching account from an entered password. To make the hashes indexable, I'm using an empty string as PBKDF2 salt.

From what I read, PBKDF2 does not protect from rainbow table attacks. Is there anything I can do to make this more secure?

I was thinking, what if I use the entered password as the salt? On the other hand that feels like it would just add one more iteration to the key-stretching, but I'm a bit out of my depth here.

Honestly, I don't see an issue with adding a field to store the salt. Or you could store the salt in the database field similar to how bcrypt does it: $version$salt$hash.

This^ is the easiest way to prevent creating a security issue. This should be the answer to the question, and if this is possible, this is by far the most recommended way.

But since you asked...

Rainbow tables trade memory for time. By creating a large lookup table, you have to generate the table only once and apply it many times (this saves time) but it requires more storage. If the attacker needs to generate a custom rainbow table for your database, there is no real benefit to a rainbow table.

A salt also protects from another 'attack': you can see which users have the same password. That is, users within your user database table, but also globally: if anyone ever used pbkdf2 with the same settings, their value for the password correct horse battery staple will match your record if anyone uses that password. If you have no unique field (other than the password) in your database, then the passwords must be unique within your database and you only need to protect from matching passwords in other databases.

The best way to do this is by using a pepper value. This is a randomly generated secret that you mix in with the password and ensures that your hashes are unique to your database. It also means that an attacker needs both the hashes and the pepper in order to crack any of the passwords. Without the pepper, assuming the pepper is strong enough (e.g. 128 bits of entropy), they will not even be able to crack the password "123456". A salt is unique per user and not secret, but a pepper is the same for all users and secret. It is usually best to apply both a salt and a pepper to stored passwords (NIST recommends that since 2017).

One safe way to mix in a pepper with a password is by using an HMAC:
password = hmac(password, pepper, algo="sha256")

To generate your pepper, you could use a regular password generator and generate a very long password. Make sure it uses a cryptographically secure random engine. The most popular and open source password managers do this.

If possible, the pepper should be stored separately from the passwords. If the passwords are stolen, the pepper might not be, and the passwords would remain safe. Since passwords are commonly in a database (like MariaDB), the pepper is commonly stored in a config file:
password = hmac(password, read_file("/etc/example/pepper"), algo="sha256")
password = pbkdf2(password, ...parameters)
if password == mariadb_query('select password from users where...') then ...

But this may be different in your situation, since you don't have usernames (or any other unique field) which is rather odd.

See also: Why do we authenticate by prompting a user to enter both username and password? Does prompting the password only suffice?

As for your proposal to use the password as salt, that only helps insofar as the password is unique. If you can guarantee the password is globally unique (and therefore also very strong, otherwise you cannot guarantee that), there is no point doing PBKDF2 anyway (any safe hash function will do, even MD5 if I'm not mistaken (of course, never ever use MD5 unless you travel back in time to before SHA2)). But if you cannot absolutely guarantee that the passwords are unique and strong enough to be uncrackable with a single pass of a fast hash function, then it's also not a good idea to use the password as salt. The whole point of a salt is to make your hashed value unique, and this defeats that purpose. Anyone who uses PBKDF2 with the password as salt, will have the same value for the same password. If using the password as salt was a good thing to do, we'd already be making our lives easy.


Secure password generation for different websites I came up with the idea to generate passwords for internet sites by the following shema:

$masterpassword
$hostname
$TLD

hashfunction($TDL.$masterpassword.$hostname)

So the actual password is a hash with a reasonable lenght of characters (depends on the hashfunction, sha512 = 64 chars)

lets say my masterpassword is "ilovesecurity", the hostname is "stackexchange" and the tld is "com". So the plainpass would be "com.ilovesecurity.stackexchange" and the hash (the password I will use on the website):

56100C52CE2B54B38AAB4E354B7826216CD6FCB3B317E7CD442D251FB0F7B378D053E705257AE9EE2D3A787D48CA8D41FB2B31C10FB97C3ACE4E1382D4B9C392

Is this "method" secure and or practicable? If yes, what hashfunction should I use? If no, what can I improve? How can I eliminate the cons?

My pros and cons so far:

Pros:

secure?
no password manager needed
"portable"

Cons:

Need to generate the hash (by tool or online hasher)
Different password policys on websites

It's only as secure as the master password. Everything else relies on the the assumption, that the algorithm is not disclosed to an attacker aka security through obscurity. Oh, and you just disclosed your algorithm to the internet.


Do I need to use the cipher command with a newer SSD to erase files? I've used Eraser in the past, and recently became aware of the cipher command in Windows 8. Specifically, with the /w flag:

  /w removes data from portions of the volume it can access and have not
  been allocated to files or directories. It does not lock the drive, so
  other programs can obtain space on the drive, which cipher cannot
  erase. Because this option writes to a large portion of the hard
  volume, it might take a long time to complete and should only be used
  when necessary.

When running it, I see it taking 20 minutes to write 0x00, another 20 writing 0xFF, then a good deal longer writing random numbers (all via the command prompt).

I'm a little confused as I've read conflicting information as to whether or not these "eraser" type methods are needed anymore with TRIM-enabled SSDs (which I'm guessing mine is).

Basically I'm deleting a bunch of old data before a laptop gets sent to the charity bin, and just wanted to do it the best way possible since I have no idea who's using it next.

I considered using dban, but right off the bat it says:

  No guarantee of data removal (e.g. DBAN does not detect or securely
  erase SSDs)

I've looked at some other answers, but they seem ~3 years old and I know things might have changed in that time.

There is an ATA Secure Erase specification for SSD drives. Not every drive and not every operating system supports this. The secure erase is a method that tells the SSD to clear all the memory cells simultaneously.  This erase method, instead of over-writing the memory cells, will tell the SSD to mark every memory cell as clear. This saves the drive from the additional damage of extra write operations. This is also secure, in that data recovery services will not be able to recover the data.

Secure erase implementations are available for Linux and there are many tutorials: SSD Secure Erase and SSD memory cell clearing.

An overview of secure erase for windows is available.  Cypher aparently does not work.  However PartedMagic does implement secure erase.  Some vendor's SSD drives will come with a vendor-specific implementation of secure erase.

This is related to another question about secure delete on SSDs: Can wiped SSD data be recovered?


Adding a new user: email temp password vs link with token I'm a developer working on a website for the first time and have a question about new user activation.

The way our site is setup now a user creates a new account and they get emailed a temporary password. The temp password gets hashed then saved in our database. The user logs in and they are told to reset their password (if we keep this method we'll force a password reset).

My concern is that I've never seen a site that does this. For new sites I always get emails with links that verify my account, and then I'm allowed to log in.

My question is which of these methods is more secure and why?

If the end user is the one who initiates the account setup and they provide a password, the use of a temporary password that they will have to change upon first logon provides no benefit. And will only serve to annoy the user.

Temporary passwords are useful when someone else initiates the account set up. As an example, a new employee coming into a company is typically provided with a domain account. You wouldn't want to let users self-register and create whatever domain account they wanted. You would typically provide them a temp password so you could control the accounts being created and to ensure that it was only them who could configure that account.  With a temporary password the end user, and the administrator know that no one has used that account if upon authenticating, they're required to change the password the first time. If the user tries their password and it's incorrect, you have the suspicion that the account may have been compromised or used by someone who acquired the temporary password and can investigate as necessary.

The non-temp password option is the most secure. Because it takes anyone other than the end user who knows the password out of the equation.


SQLMAP Redirect using xampp I am learning SQLi using sqlmap and xampp.

I set up my lab the same way as per tutorial but when I run

sqlmap.py -u "http://localhost/bwapp/sqli_1.php?title=1*"

the error got 302 redirected to

http://localhost:80/bwapp/login.php

and when I clicked either yes or no, then I get the error

"you have not declared cookies, while server wants to set its own.. ..".

How do I solve this issue?

Would be helpful if you give further information:

Bwapp Version
What tutorial
What sqlmap version

So sqlmap gives you a hint:
You have not declared cookie(s), while server wants to set its own

This is the note that you haven't delivered any cookies using sqlmap.
This means you are not logged in and you will be redirected to the login page
Redirect 302 to
http://localhost:80/bwapp/login.php

So you can give sqlmap your login session using
sqlmap -hh | grep cookie
    --cookie=COOKIE     HTTP Cookie header value (e.g. "PHPSESSID=a8d127e..")
    ...
    --load-cookies=L..  File containing cookies in Netscape/wget format

So a workaround (I have no bwapp in front of me) could be:

Log into bwapp in the Browser
Go into Developer Tools (Ctrl-Shift-I then: Chromium -> Application -> Cookies or Firefox (web-)storage)
Remember the cookies from here
Give it to sqlmap with --cookie "name1=value1;name2=value2" e.g.
sqlmap -u "http://localhost/bwapp/sqli_1.php?title=1*" --cookie="security=low; PHPSESSID=oikbs8qcic2omf5gnd09kihsm7"


Find malware in browser extensions How can I check if an extension/addon consist of malware code? Is it easy to detect if it collects sensitive data (like spyware), logging keystrokes and so on? Can AV recognize malware extension as "bad"? Can an extension exploit browser vulnerabilities?

I'll answer these separately:

  How can I check is extension/addon consist of malware code?

Usually browser addons exist as a file archive somewhere, within your browser's application files. You can find out where by doing a quick Google search. Once you've found the file, upload it to somewhere like VirusTotal. You could also extract the files (most plugins are just renamed .zip or .tar files) and manually dig through their code. Certain browsers also load DLLs as "browser helper objects" (BHOs), which can contain malicious code. These can be found and scanned in the same way, and Autoruns will tell you which BHOs are loaded into IE.

  Is it easy to detect if it collects sensitive data (like spyware), logging keystrokes and so on?

Depends on the malware. Keyloggers usually hook APIs related to processing keystrokes, which most AV software can detect or prevent. There are other methods though, so it's not possible to catch all logging mechanisms. Spyware almost always phones home at some point, so you can keep an eye out for unusual network connections in your firewall logs.

  Can AV recognize malware extension as "bad"?

Most can, yes. Some will only process executables (exe, dll, sys, etc.) on standard scans, but you can fix that by running a deep or full scan. On-access scanners should pick out known malware in any file the moment it's accessed.

  Can extension exploit browser vulnerabilities?

Yes, but sometimes it's not even necessary. In older (and crappier) browsers, a plugin is already native executable code running at the same privileges as the browser. Modern browsers tend to implement their plugins in a sandboxed scripting environment. There may be vulnerabilities in those scripting engines that allow the malware plugin to escape and escalate.


Can a domain administrator read my search queries? Google's privacy policy states that they log your search queries. They also state that domain administrators have access to your Google Account information (e-mail and "other data") as well as information stored as part of your account. Barring something like a law enforcement investigation, can the domain administrator arbitrarily read my search queries?

N.B The domain administrator's privacy policy links to Google's privacy policy.

You'd need to discuss specifics with Google and your domain admin, especially since much depends on the exact set up of you apps account, but it is a safe assumption that the domain administrator will be able to see almost as much as google can when it comes to your apps account activity. After all, they're paying for it.

(Also, good chance they are paying for the network and the computer you're using as well, so they may well be able to see everything being done with those resources as well.


Generating random passwords by clicking randomly on the keyboard? How secure is it to generate random strings/passwords manually for different purposes by just clicking randomly on the keyboard ?

I usually need random strings for salts and for passwords, and I wonder if that method is sufficient or not, or do I need a strong algorithm to generate the passwords for me.

Assuming that I will include numbers and maybe special characters and small/capital letters

Such passwords will be as random as your fingers can be. Humans banging on keyboards tend not to be very random; for instance, they will often alternate between left-side keys and right-side keys. As a rule of thumb, such a passwords would probably be reasonably secure if you make it long enough, about twice as long as a random password generated with a good randomness generator.

The main problem with a password crafted with such a "manual process" is that it is very hard to quantify its randomness. Especially if you generate several such passwords: I would expect successive "keyboard-random" passwords from the same human user to exhibit similarities. Thus, you have to overdo it in order to regain some guarantees, which means longer passwords (and nobody likes to type long passwords).

I recommend using a strong random generator. Dice will do; coins too (but a d20 will give you more randomness per throw than a coin). If you happen to have a computer available at that time, well, it can be used too.


Passing encryption with IV as a single array I am fairly new to this, so I'm sure it has been asked and answered but I cannot find a clear answer.  If this has already been addressed, please point me in the right direction and I will remove this question.

I have a program which will need to accept a username and password from the user.  This username and password is for another server, but the information will need to be passed around a few DLLs before sending the final request to the other server.  My concern is with passing usernames and passwords between DLLs without encryption, so I have made a simple Encrypt and Decrypt method set using Microsoft's System.Security.Cryptography.CryptoStream class.

Essentially, the following operations are performed.

A plain string is entered into the encryption method along with the encryption key.  This method then generates a random IV (8 byte), random array (8 bytes) and the byte array encryption.  The IV, random array, and encryption are then put into a single byte array and passed around between DLLS.

The byte array is received by a DLL and passed through the decryption method with the encryption key.  This method grabs the IV part of the array and the encryption part of the array, and ignores the random 8 bytes added (these are added simply for totally arbitrary reasons).  The string is then decrypted.

Have I accidentally broken the whole security of using an encryption by appending the IVs to the encrypted byte array?

Should I be using the random 8 bytes as salt (just, since I have them anyway) and passing them through with the encryption?  Or would that just break it even further?

Note that I have no direct access to a list of usernames or passwords, this is an entirely external application.  I just want to ensure that the request and movement of username and password pairs are secure on my end.

IVs are not secret and it is common to pass them along with ciphertext. That part is not a problem. Since you didn't say what threat you are defending against, I will assume you worry about reading the password from memory directly or from memory dumps. In that case you might have a different problem with your approach: strings.

Strings in .NET are immutable and you cannot clear it after you are done with it. If you assign an empty string to a variable, the old value will remain in memory and you will get new empty string object in its place. Even if you create a byte array and encrypt it like you proposed, the left over string will remain in memory and will wait there until Garbage Collector clears it.

If you don't control the way passwords are received, this might be impossible to solve. You need to make sure password is never stored in a string. Let's assume you can solve this part. Your options then would be:

You can either always use byte arrays and do encryption like you described (salt is not required, just make sure you never reuse key/IV pair and generate random IVs with strong CSPRNG) or
Use SecureString.

SecureString is designed to solve exactly the problem you describe without the need to "roll your own".

Introducing cryptography primitives into a solution and believing it will make the solution more secure is deceptive. Sometimes the scope of the problem is much larger than you realize.


How to get rid of geolocation info on linux? First of all: I HAVE read the "Why does Google know my location?" posts but still in my case it is a bit weird / the solutions cannot fit.

The Setting:

Fresh installed linux. Never ever logged in into a google-account or something like that on that machine.
VPN using OpenVPN. Working according to those "show me information to my IP" - sites
Location Services Disabled in Chrome browser

Still: Netflix displays "not available in your country" and google maps still displays my position (roughly)

I know about the possibilities for google to save my Routers MAC etc. but the following is also true for my network:

Netflix does NOT recognize me when connecting via Windows-PC
Also not when connecting via Android- Device (with disabled gps)
(All devices use the same VPN and the same LAN)

So there must be something "in the machine" / the OS that offers Netflix the geo information it needs.

Any idea what this could be? And especially: How to avoid that / fake it? (I would be fine if the OS also is tricked about my location)

It is a clean Ubuntu installation with only XBMC installed if that matters.

Got it. The Linux system uses IPv6 while my Windows System isn't.

Also the Test-Sites I checked only checked the IPv4 - Adress telling me everything is right


Is a mail secure if it's PGP-encrypted, but unsigned when sent with DKIM? I run my own mail server and would like to use different addresses on the same domain.  If I were to sign mails from those addresses, I'd have to generate new PGP keys for each and every one of them.  This could become unmanageable very quickly.

As I understand it, DKIM signatures prevent the mail from being tampered with by other parties.  Would it be possible / make sense to leverage DKIM for mail signing and just encrypt mail, skipping PGP signing?  If it's possible, what assumptions would one have to make to reach comparable security?  Would a DNSSEC secured domain be enough?

First, DKIM only gives you the assurance that:

  a DNS administrator was involved in the process of signing this message.

That DKIM signature is intended for a reputation to be built with a "selector".  A selector (signing key) is issued:

per user
per groups of users
per domain.

The granularity of that signing is undefined in the RFC and up to the DNS admin.

If you're OK with that flexible, possible anyone-can-sign assurance, then you are OK, but I'm not sure what that will give you.

Next, DKIM has three modes:

Full
Headers only
Partial signing (with the -L (length) parameter.)

The latter two means the encrypted content can be replaced in its entirety with another payload.

Unless you have a very strict implementation of DKIM, it's not a substitute for authenticating an end user (unless all you care about is the DNS name)

I spent time on the RFC working group but left in the late draft stage, so I'm 99% sure that this stuff is still true.


Why do CPUs operate speculatively with results of forbidden memory fetches? By my understanding, the Meltdown and Spectre attacks both exploit the fact that some modern processor, when given something like:

if (x < arr1[y])
  z = arr2[arr3[x]*256];

may sometimes fetch the value of arr2[arr3[x] * 256] before they have determined whether x is less than arr1[y], and may do this without regard for whether code has adequate permission to access arr3[x].  The portion in italics is the sine qua non of the vulnerability: if the processor were to only fetch arr2[arr3[x] * 256] in cases where the access to arr3[x] was permissible, it would be impossible to exploit an to arr2[___ * 256] using illegitimately-fetched arr3[x] values because there wouldn't be any.

It makes sense that even if arr3[x] is invalid, the processor can't trap unless or until it determines that x is less than arr1[y].  What I fail to understand is why a speculative fetch from an invalid address shouldn't cause the CPU to abandon the current speculative execution path?  I would think that in almost every realistic scenario one of two things would happen:

The branch prediction that led to speculative execution turns out to be wrong, in which case any work that might be done with the speculatively-fetched value will need to be discarded.
The branch prediction that led to speculative execution turns out to be correct, in which case execution should trap at the invalid access, and work that might be done with the speculatively-fetched value (before executing the trap) will need to be discarded.

Is there any realistic scenario in which speculative work that follows a speculative fetch from an illegitimate address could turn out to be useful?  If not, what advantage is there to allowing speculative execution to continue past such fetches?  If an invalid fetch will make the CPU abandon the current line of speculative execution, that would avoid the need to keep track of speculative pending traps.

Consider the following code:

mprotect(arr3, sizeof(arr3), PROT_NONE);
...
mprotect(arr3, sizeof(arr3), PROT_READ);
z = arr2[arr3[x]*256];

At some point, arr3 becomes readable by the process.  If the assignment (well, actually the dereference of arr3) has already been loaded before the mprotect completes, what behavior would you expect?  I would not expect a trap, since it's valid at the point.

Basically, you don't know what the state of the memory at arr3 is until the instruction before it has been retired, at which point the pipeline will have executed well past that point.

I suppose you could "speculatively trap" and re-execute if the memory permissions change in the mean time, but apparently that's not what is done today.  (Though I imagine it would be a much smaller performance hit than the KPTI software fixes.)


Hardening charity volunteers' access to a web server I'm helping to administer a LAMP web server for a charity which runs CiviCRM on Joomla. This system is going to be accessed over the Internet by many volunteers from devices I have no control over.. Are there any professional tried-and-tested suggestions for hardening given such a scenario?

For example, one way could be through a VPN and a spreadsheet that lists users & devices with access together with their "security readiness state":

Username
Access granted (i.e. group membership)
Access needed (i.e. gently making people justify being admin..)
Device name
Device location
Device OS
Device security software in use
Link to device-specific security checklist
Date security checklist last ran
Device VPN key thumbprint

The spreadsheet could be viewable organisation-wide, thus encouraging transparency and accountability, hopefully giving me leverage in getting users to at least adopt the standards of their peers. To do this I would be interested in ways of auditing a device's security posture. If it could be audited and enforced by the VPN (quarantine & remediation) that'd be even better.

Are end-user devices provided to the volunteers by the charity? If not, are you really sure that you want to personally take in charge the hardening and ensuring support of all volunteers' devices of all kind?

Unless you are in a corporate-like environment where devices are provided and managed by the company, you would rather consider that end-user devices management is up to the end-users themselves. This does not prevent you from giving useful advises, but nothing formal and nothing engaging you to provide some kind of universal support service to the end-users.

On your side however, if required you can try to detect suspicious activities on the server side and prepare an action-plan in case such alert would be raised. For instance, you can tell the users some example of activities assimilated as suspicious (it can be the same user connecting suddenly from a different country, posting advertisements / offensive / unusual messages, manifestly trying to penetrate unauthorized areas, etc.) and explain what would follow (revocation of the VPN access, user contacted by phone / mail / whatever, etc.).

I talked about a VPN because you mentioned, but if all you want to provide access to is a website, client-side certificates may be a lighter and more appropriate option than a full-fledged VPN.


Is the 3DES algorithm secure? Can we use the 3DES algorithm for exchanging confidential information? I am using it in my project. Security code reviewer has raised a bug saying that it is not secure but I see that it is mentioned as secured in CMMI.

NIST still recognizes 3DES (ANSI X9.52-1998) as a secure symmetric-key encryption algorithm when configured to operate as described in NIST SP 800-20. There are still Cryptographic Algorithm Validation Program (CAVP) certificates issued for 3DES in 2016. However, many open source projects (e.g. OpenSSL) and international certification standards (e.g. Common Criteria) already deprecated 3DES.

The reason 3DES is being phased out is due to various vulnerabilities (e.g. collision attacks like sweet32). While there are still ways to compensate (e.g. frequent rekey, disabling CBC mode) to prolong its life, there is no good reason not to switch to AES.

So are you vulnerable RIGHT NOW? Not if you correctly implemented and configured 3DES. Should you be planning your move to AES? Absolutely! It is only matter of time until 3DES is too broken to be considered secure.


Do credit cards which utilize an embedded chip but also have a magnetic strip, still benefit from the added security of the chip? I understand why credit cards with embedded chips are more secure (since they generate one time codes), but does this affect the added security benefits provided by the chip?  Can cards still be cloned as long as they have magnetic strips, even if a chip is present, because of this?

Obviously some locations don't have chip-enabled terminals yet, so embedded chips can't be used for transactions everywhere.  However, because of this, the card is still able to be read via magnetic strip (and thus able to be copied, since all the magnetic strip does is provide the card information unencrypted, no?).

For example, couldn't a thief install a credit card reader of his own at the point-of-sale, accumulate card data from people that way, and then duplicate people's cards to use?  How can the chip prevent scenarios like this if it's not required (and magnetic strip can be used instead)?

Edit:  The article suggested that answers this post, doesn't. It touches on the subject but doesn't provide a full answer. It says:

"..the magnetic stripe and the chip are used in two different ways, and having both does not mean that the security is lowered to the security of the weaker of the two. ...chips are better, because they are more efficient (no need to handle a network call) and harder to clone (statistics show a fraud rate divided by about 10)."

It explains why most transitional cards have both, but doesn't provide many details about security advantages or disadvantages of pin/chip (separately or together).  Why doesn't the magnetic strip compromise the security provided by the chip, especially if the chip is compromised somehow? It seems to, so my question still remains.  The article suggested as answering this post, just simply doesn't.

Also, korockinout13's answer (https://security.stackexchange.com/a/136416/52840) seemed to tell me what I wanted to know, but it seems to have been downvoted a lot, which seems odd considering it seemed to answer my question.

Most terminals that are pin and chip enabled will force the user to use the chip when it is present on the card.  The transition will be long in the usa, so the magnetic stripe is there for backward compatibiliy.


If you SMS text someone, how much more information will they know about you? If I send someone a text, how much information am I giving up? Could they add me to an app like Whatsapp and access my name and profile? Or does their number first have to be saved in my phone contacts for that to happen? What other information could they access just from a text message, assuming I have not added them as a contact?

If you publish you mobile number in a directory such as Spokeo they can look you up

If you use Telegram, the other person will be able to see your public name. Your last seen online time could be retrieved either precisely or imprecisely depending on your privacy settings - this information cannot be hidden completely. Telegram will always tell anyone whether you're currently online (using the app) or not. You can make your profile photo visible only for your contacts.

If you use WhatsApp you can hide your last seen info and profile photo completely from everyone. Your public name can also be seen by anyone regardless.

It's trivial to find out what your cellular operator is and in many cases it's not difficult to pinpoint the location where the SIM card was sold to you.


How bad is to render html from cookies? Recently I worked with a PHP framework and saw that it was putting html in a cookie to read it from javascript (don't ask me why).

I tried to alter the html in the cookie by putting an alert('bingo') instruction and it worked. Can this behaviour be used as main channel for XSS assuming no other server side vulnerabilities are present?

In other words: how can an attacker use this behaviour given this is the only known vector?

Assuming there are no other vulnerabilities in the website I don't believe this is exploitable, as in order to exploit this the attacker would first need to be able to control the contents of that particular cookie. (Which would almost certainly require the use of some other vulnerability.)

However, if there are other vulnerabilities (whether they be client or server-side) in the site this unusual feature could be used to make the impact of those vulnerabilities significantly worse.

For example, if any page on the site is ever loaded over HTTP, a MITM attacker would be able to create a semi-persistent XSS attack by setting the value of this cookie, possibly using the attack to steal data that would normally only be accessible from a more secure HTTPS page (such as cookies with the secure flag set).

Or if the site is vulnerable to a Cookie Tossing attack, that same attack (which would normally only be useful for session fixation and the like) would also open you up to a full-blown XSS attack against affected users.

All-in-all, while this practice may not be terrible I still wouldn't advise it, especially since there are much better ways of getting HTML content from the server onto a page that don't expose you to any new threats.


Fear of mac Spoofing. Two Mac addresses appearing on Router page with only 1 digit variation I have tried looking into Info Sec's posts for a related issue but couldn't find a solution as my problem is a bit specific.

I have been having connectivity issues, and as paranoid as I can get, i wanted to see if there was any foul play as I was finding a lot of strange, sporadic appearances of Wifi networks in my vicinity.

Prior to these networks appearing I had no connectivity issues. Regardless, to simplify and get to the point, I went to take a look at the attached devices on my router administration page to suss out any potential intruders.

I've just come up to see two mac address appearing on the list, however I am the only connected device. To clarify I am connecting to a Wireless Extender.

This is where the issue is: The two Mac Addresses are ALMOST ALIKE save for a 1 digit variation. However what is interesting is that the Mac address that is not my NIC's original physical address is assigned to my IP and Vendor {MSI} while my original Mac address is listed as an unknown.

(I have attached the image of my devices page below to show this.)

Is there a possibility that I may be Mac Spoofed or am i being too worried? I am not familiar with protocols or measures used by routers as I am a home user. Perhaps the router needs to duplicate my mac address and amend it for internet connectivity?

It is likely that your connectivity problems are because the new wifi networks are conflicting on the same channels. Change channels.

The reason why you are not coming up with answers on infosec forums is because this isn't an infosec issue, this is a basic networking issue. Many devices have the 2 MACs for a single device. There is actually a duplicate of t

By the way, the router does not modify your MAC for connectivity.


Why is a "tainted canvas" a risk? I understand the concern about a tainted canvas - the idea that the bits of an image from another site can be sent back to a malicious server. But can you explain the details of how exactly this works?

Suppose the user visits nastysite.com and nastysite.com makes an image request to mydatingsite.com or mybankingsite.com to get an image that contains information that is private to the user, and then renders this image onto a canvas, gets the bits of the canvas, and sends those bits back to the nastysite.com server.

What exactly would that image request URL look like? Say it's your picture from a dating site profile you are logged into with a session cookie (mydatingsite.com), or a check image from a banking site you are logged into with a session cookie (mybankingsite.com). How does nastysite.com know what specific URL to use? And does it work if the connection you have to the dating or banking site is through HTTPS is part of a particular session?

I guess this is really a question more about session cookies. Does nastysite.com have free access to your session cookies for mydatingsite.com and mybankingsite.com? Can it use them in an image request that the mydatingsite.com and mybankingsite.com servers can't tell isn't a normal session request from their own page?

What exactly would that image request URL look like?

It need not be anything complicated or abnormal. There are two main ways this could work (were it not for the restrictions in the browser):

In the first, there is a specific URL for the profile image of the current user, say http://mydatingsite.com/currentuser/profileimage.jpg. This might be an odd way to design a site, but I have seen it used. This sort of attack works against anyone logged in, and you do not need a customised URL for your target.
The second works for attacks targeted at a specific user. If I know you are the owner of the check with ID 12345 I could find out what it looks like by using a URL like http://mybankingsite.com/checks/12345.png.

  How does nastysite.com know what specific URL to use?

As an attacker you have to do some research. You can find the URLs or at least the formats of URLs in the source code of the page you are trying to get data from.

  And does it work if the connection you have to the dating or banking site is through HTTPS is part of a particular session?

Not sure what kind of session you are talking about here. But in general it would work as the user is logged in to the site in question in the same browser as they visit nastysite.com in.

  Does nastysite.com have free access to your session cookies for mydatingsite.com and mybankingsite.com? Can it use them in an image request that the mydatingsite.com and mybankingsite.com servers can't tell isn't a normal session request from their own page?

You are right that all this comes down to cookies. You can not read cookies cross origins, so nastysite.com has no idea what your sessionid on mydatingsite.com is. But for this to work, there is no need to read cookies! The browser is kind enough to send cookies on all requests, no matter what origin the request comes from.

If browsers did not mark canvases with cross origin data as tainted, this would be a real problem. You would have a situation similar to CSRF, where all servers needs to have protection in place to stop cross origin mishaps. New features such as canvas should not break backwards compatibility and force all existing sites to adapt. That is why the tainted concept was introduced.

Note that short of browser bugs this is all quite theoretical since browsers should stop this kind of attack.


Reporting leaked passwords in github repository I have just found a handful of repositories on github that contain database passwords. I want to let the concerned parties know about this so that they can change their passwords and remove the password from the git history.

All of these repos look to be web sites built by web agencies for their clients. All the repos are under the same account, each repo refers to different web agencies.

I'm not sure how I should proceed. I don't think that I should just open issues, because this would just put more light on the issues.

How should I proceed?

You should be able view the email address associated with a commit to the repo in the git log, the easiest way to view this on github by adding .patch to the URL

for example:

https://github.com/git/git/commit/9d77b0405ce6b471cb5ce3a904368fc25e55643d

the patch URL is:

https://github.com/git/git/commit/9d77b0405ce6b471cb5ce3a904368fc25e55643d.patch

This will give you the commit data, from which you can get the author's email address - you should be able to contact them on that!