What "hacking" competitions/challenges exist?

I don't know a good reference to point to for further reading. Thus I will try to list a few time-wasters that I personally enjoy.
In the following I will allow myself to differentiate between various styles of hacking competitions. I don't know if this is a canonical approach, but it will probably help explaining the differences between the ones I know:
Wargames
These games take place on given server, where you start with an ssh login and try to exploit setuid-binaries to gain higher permissions. These games are usually available 24/7 and you can join whenever you want.

Over The Wire
Smash The Stack
Intruded

Challenge based competitions
These games will present you numerous tasks that you can solve separately. The challenges mostly vary from exploitation, CrackMes, crypto, forensic, web security and more. These games are usually limited to a few days and the team with the most tasks solved is announced the winner.
I will list my favorite, since I am quite convinced that you will easily find more of them. Some of the listed have just taken place and others will take place in the following months.

Defcon Quals
Codegate Quals
CSAW CTF (usually during summer)
Hack.lu CTF 2011 (end of September this year) and Hack.lu CTF 2010
PlaidCTF

Capture The Flag
These actually require you to capture and protect "flags". The best known is probably iCTF, which underwent some rule changes within the last years. This game is also limited to a certain time frame. Contestants are typically equipped with a Virtual Machine that they are to connect to a VPN. Your task is to analyze the presented machine, find security bugs, patch them and exploit the bugs on other machines in your VPN. The "flags" are stored and retrieved by a central game-server that checks a team's availability and whether previously stored flags have not been stolen.

iCTF (typically in December)
CIPHER CTF (will be renewed by new organizers this year)
RuCTF and RuCTFe (a Russian CTF and its international version)

Other
There are also a bunch of downloadable virtual machines available to play offline, which is some kind of mix between 3) and 2) I suppose.

Damn Vulnerable Web Application
Damn Vulnerable Linux
Google Jarlsberg

Edit:
Tag
I have just come across a fifth game-type that I have not seen anywhere else. All teams compete with each other during several rounds and each round is a match between two teams. Phase 1: Both teams get root on a Linux System and try to hide as many back-doors within 15 minutes as possible. After these 15 minutes, the teams swap PCs and try to discover and remove as many back-doors as possible (also with root access). In the third phase, each team gets its server back (without root access) and is supposed to exploit as many back-doors to gain root access again.  Remotely exploitable back-doors get bonus points :)
It appears that games like this has been carried out during the LinuxTag Linux Conventions in Germany in the last years.
The scenario is explained more detailed here (German only!)
/Edit
I hope this post has not become too confusing due to its length ;)
Unordered list of lists of Hacking competitions:

http://capture.thefl.ag/practice-ctf/, Calendar
http://www.wechall.net/sites.php
http://exploit-exercises.com/
http://www.stumbleupon.com/su/1YNSxi/www.brighthub.com/internet/security-privacy/articles/77093.aspx/


Have you tried including quotes to break this? From what I see here, it should actually cause a horrible error if a quote is passed in. Sometimes you have to fiddle around a little before the crash happens.

$query = mysqli_query($con,"SELECT * FROM users WHERE name='$user'");

Here is my attempt to break this:

'OR 1=1--

It appears you have not used parametrized queries, therefore leaving your code open to injection. Note the above is just a proof of concept - with your current code it wont actually let you do much that you can see.

Your code validates the results of the query after it is executed, which is very dangerous. You are open to SQL timing attacks at the very least.

Instructions for implementing Parametrized queries are below:
http://php.net/manual/en/mysqli.prepare.php
https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet

Additionally:

1)As a beginner you are much better off using a pre-made ORM.

2)Input sanitization is key. Always do this before the data gets into a query.

3)If you are doing this to learn security, try a pre-made war game of a similar ilk - it may give better guidance for learning to exploit the bug.

Disclaimer:
I don't know this particular PHP API too well, so if it's doing parametrized queries by default, I couldn't tell or was not aware of it.


Security of an initial redirection from http://example.com to https://example.com

As far as I can see, there are two vulnerabilities here:

The Secure flag isn't set. The initial HTTP request will leak the session cookie either from a session created by the instance at http://example.com or from a previous session created by the instance at https://example.com. The same leaked session identifier will be reused -> The attacker will have access to the session.
The initial HTTP request is intercepted and the response is replaced with one that plants a cookie with a session identifier for a session started by the attacker. Subsequent requests will reuse the same cookie. This is a form of session fixation attacks.

In both cases, when reaching the HTTPS instance, the server has no way of knowing whether to invalidate the previous session or not, as the session can be the legitimate one started by the user.

The only solution I see here is to invalidate and recreate the session when a request is made to https://example.com and then use cryptographically-strong tokens in addition to the session cookie with subsequent requests. The token needs to used one time and one time only.


Informative error messages in password reset functionality?

This is current best practice, as recommended by OWASP. One thing often overlooked though is that the return values should be identical - the layout and underlying HTML code for a page should be the same for each. It's not enough just to provide the same message if you can open the page source and see a comment <!-- Failed password --> or <!-- Unknown email address --> - I have seen these in live sites.


Decoding a HMAC SHA256 when the key is the same as the original string

How easy would it be for someone to decrypt this, knowing that the original message equals the key?

If all you know is that they key equals the message, then attacking the HMAC practically impossible. If you look at how HMAC gets computed you can see that you would somehow need to get the input to a SHA-256 hash from a known output. This would mean you need to mount a successful pre-image attack against SHA-256 which is considered practically impossible today.


Turning off the verification will not mean that the data is sent unencrypted. The data will still be sent over HTTPS (an SSL/TLS connection), but the validity of the certificate from the server will not be verified with the certificate authority that issued the certificate.

In your case, because you signed the certificate yourself, you should indeed disable the verification check. Your certificate cannot be validated/verified by an issuing certificate authority, because your certificate is not issued by a certificate authority. Ergo, you should disable the verification check. The data will still be sent encrypted, but this does of course present some security concerns, because a clever MiTM attacker could introduce a bogus certificate for the client to use. As such, I would recommend getting a certificate issued from a CA, but if you want to stick with your self-signed ticket, then just disable the verification check.


Patch management for avoiding issues like EternalBlue

As with the patches for the vulnerabilities used by the ransomware, there was no negative impact described by Microsoft.

In a utopia, system administrators would be patching systems on a near daily basis. However, in the real world, it is the complete opposite.

Some updates may have to be reviewed, such that they do not negatively impact the productivity of an enterprise. While rare, some institutions consider down time, and the potential loss of work to be very significant.

Systems may not be connected to the network, or may not be connected to a corporate server that instructs for the deployment of certain updates. Laptops are notoriously known for being behind on patches because of their portable and unconnected nature.

Furthermore, some institutions may have patch cycles, such that a patch might be public, but not deployed for a month or more.

There was no valid excuse for the impact of the ransomware, as the patch and notice was public March 17th, but the vulnerabilities were taken advantage of almost 2 months later (May 12th).

You can read the security bulletin by Microsoft here: https://technet.microsoft.com/en-us/library/security/ms17-010.aspx


What issues are most important to cover in Corporate Security Policy?

Key points:

It should outline the security acceptance/appetite of the organisation in order that the standards which support the policy can be defined in the correct environment.

It also needs to define responsibilities, ownership and sponsorship.

Updated just to provide some examples, as I did leave this pretty light. At high level you should have at the minimum policies to allow you to measure, understand and regulate your technology risk. These will also be required from a governance perspective in a lot of environments -

Information Security Policy
Information Classification Policy
Acceptable Use Policy
Data Retention Policy
Data Protection Policy
Risk Assessment Policy

You will probably also want to look at the following if you provide services or products to larger organisations, as they may run a governance scheme which includes their 3rd parties -

Corporate and Social Responsibility
Policy
Environmental Policy
Equal Opportunity Policy

In the UK you must define your data protection requirements with respect to the Data Protection Act 1998. You should also construct your policy framework taking the ISO27001 family of standards into account, as many security audits and assessments for the regulator and for the IT piece of statutory audit are structured around 27001.


Whats the difference between certificate pinning and a truststore in Android/iOS?

Certificate pinning and a TrustStore are not the same concept. The difference is not necessarily in trusting the certificate vs trusting the public key used in it. You can pin certificates too.
Android's Trust store essentially contains of a bunch of certificate authority that are trusted by the Android developers or users(they can manually add root certificates). When you validate a certificate using a Trust Store, you know that the certificate was created by the trusted root and the certificate was meant for a particular host. This approach leaves you vulnerable to situations like the root CA losing its private key.
As mentioned on OWASP, certificate pinning is a good way to stay away from problems like these. I am going to borrow a paragraph from that article which might help you understand the difference:

When Do You Pin?
You should pin anytime you want to be relatively certain of the remote host's identity or when operating in a hostile environment. Since one or both are almost always true, you should probably pin all the time.
A perfect case in point: during the two weeks or so of preparation for the presentation and cheat sheet, we've observed three relevant and related failures. First was Nokia/Opera willfully breaking the secure channel; second was DigiCert issuing a code signing certificate for malware; and third was Bit9's loss of its root signing key. The environment is not only hostile, it's toxic.


SqlMap bypasses OWASP ModSecurity Core Rule Set for SQL Injection

I've managed to make ModSecurity detect and prevent SQL Injection! The problem was with the SqlMap itself and not the OWASP Rule Sets.

Before enabling ModSecurity I performed a normal sqlmap scan using the command mentioned previously. SqlMap managed to obtain and decrypt user and password values. I was expecting that to happen because I had no WAF enabled.

The next step was to enable the WAF and SQLI rule sets and perform the same scan. SqlMap still managed to get user and password values. The reason for that is because it obtained the cached results that were saved after I had performed my first SqlMap scan with no WAF enabled.

I deleted the whole sqlmap output folder related to that specific IP address where the DVWA was hosted.

rm -rvf /usr/share/sqlmap/output/192.168.220.128*

The final step was to run the sqlmap scan again, and this is what I got:


Help understanding basic user authentication with salts and hashing

In your title you are talking about basic authentication, I assume you are talking about HTTP basic authentication, which is when the browser prompts you for a password, encode and sends over the wire. However, you do not really control the mechanisms and encryptions with that method. It's also generally not used because its less secure and you can't add things like SALTs, one time pins, captchas, etc.

Likely, you want to implement form based authentication using an HTML form which sends the form data with POST. You should secure the submission of this form using SSL/TLS with a certificate for general public usage. This helps to limit the ability for man in the middle (MiTM) attacks where an attacker can eavesdrop and capture the username and passwords. You can do encryption on the client side using JavaScript, but you still need the initial password stored up front. I have seen this implementation on only a few pen tests, but its not very common to do it with JavaScript like that.

Now, in regards to salting and hashing, and everything like that. This is more to do with the storage of the credentials in the database. Typically, you receive the password without encryption through the SSL-secured form submission. You don't want to store the actual password in your database, so you hash it and you salt it using your hash algorithm (e.g., bcrypt). The salt+hash make it so you can store the password without it being directly stored. Hashes are one way so unless you use a technique called rainbow tables, you would have to brute force every possibility until you ran through the algorithm and got the same result. Using a salt make it more difficult to use rainbow tables because the rainbow table must take into account the salt and cannot just be the "standard" rainbow table.

You can have a per user salt or one you use universally, a per-user salt would be more secure. In your user table in your database you would store the following

the username
the hash(salt+password)
the salt for this user

Now, when a user comes to log in again they submit their username and password in the form. You then want to see if they are in the table so you then:

Look up the supplied username in your database and return the hash and the salt
Take the provided username and rerun the hashing function using the salt obtained in 1 to do somehting like hash(salt+password submit on form)
If the hash generated in 2, matches the on retrieved from the database in 1 then you know they provided the correct password

The whole point is to not store the actual password and to make it computational expensive to figure out what this random set of characters maps back to (i.e., difficult to determine the real password).

Some further reading

An implementation using JavaScript on the front end
A decent tutorial I probably could have googled first before writing all of the above.

Update
OP Asks about not sending through SSL:

You need to accomplish to separate things here: (1) secure data in transit and (2) secure data at rest. What we talked about with hashes accomplishes securing at rest. To secure it in transit, you need to ensure the data going over the network is encrypted somehow. It sounds like you don't want to obtain or cannot obtain a SSL certificate. This is generally the most common way. Otherwise you could implement a much more complex programatic way, where you have your own private and public keys. You more or less encrypt the data before its sent with your private key using a JavaScript implementation of PGP or similar. This is not recommend because you can easily mess it up and it requires JavaScript, which your users may not have enabled. You still use the salting as described above, you just encrypt at the client with your public key and then decrypt on the server end with your private key, then continue as if it was transfered with SSL.

Algorithm (caveat - requires JavaScript or other client side language enbaled)

Create a log in form, do not set a submit action in the form - we don't want the information sent through normal means because its confidential and we are not using SSL
Create a JavaScript handler which is used to submit the form, as part of the processing, encrypt the password field with your private key, then submit it using HTTP post.
Once received on the server, decrypt with public key
You have now transfered the actual password over the network with encryption
Change you private-public key pair frequently to reduce compromise or reversing.
Continue with securing at rest as detailed above.

Update 2
OP continues question to know more about securing session variables:

It's always best to put all submission over SSL to protect eavesdropping. Even if you hash all of your cookie data, if I can intercept and I just need to send you back the hash, well, I already have it if I can be MiTM. You should use multiple factors to limit session hijacking and CSRF attacks. Rather than going into deep detail here, you may want to check out the OWASP Top 10 and read through the various security concerns and how to mitigate. OWASP is one of the top resources for learning how to secure web apps.

The second question you are asking is if your server side app is doing logic basic on a user id being passed can this be faked? Yes, use session management to determine the current user, don't let the client tell you who they are after authentication.

This article, also related to the questions you ask and may be useful for you.


How should an outgoing connection white-list be created?

In my opinion this is a pretty well rounded analysis but there are a couple points that could use improving.

Basic bidirectional firewalling is a good start but unless you have the ability to get into the actual application level traffic - be that with a HTTP proxy application level firewall or what have you - there is still a major hole in your security.

A lot of firewalls today - even those that advertise application level analysis - don't do application level filtering for all protocols. Picking a common port number for a malicious cause is a pretty easy way to get around a tightened down firewall. Whenever you can it is always best to whitelist your definitions, even for the semi common protocols.

As an example I've previously experimented with a TCP service bound to port 123 on an outside host I was experimenting with. I was surprised that I was able to get to it from a protected internal network without any additional firewall rules. Turns out the the NTP definition included both UDP and TCP ports and was allowed out to anywhere.

About the only protocols I don't do that with are HTTP, HTTPS, FTP, and SMTP. Each of those has some kind of application level filter available configured for my my clients.

EDIT:

All this changing terminology is making me feel old.. Looks like the suggested terminology for the device I'm thinking of is a UTM (Unified Threat Management) gateway.


That's indeed malware. The protocol is IRC, which it's using for its command-and-control.


As a Software Industry Editor, how to avoid my software being quarantined?

Most AV vendors have some form of a "Trusted Software Vendor List". Any binary signed by a vendor on this list automatically gets trusted, so you do not have to beg for each binary to be whitelisted. Symantec had one but cancelled it.

Some AV vendors will adjust their detection score if you simply sign the binary (which is a little scary, in and of itself).

You are correct, there is no one-size-fits-all solution. And there shouldn't be. Think of the opportunities for abuse if there was some kind of central list or a universal way for a new binary to be automatically whitelisted by all products.

If your software performs risky functions, then it is legitimate for AV to protect the system from it.

There might be ways to make your process more efficient, though. You could submit a non-production version your new binary to VirusTotal and then go through the process for each product (apply for whitelist, submit a "false positive" report, etc.) that pinged on your binary. If you submit a production version, then the hash of that binary might be quarantined faster in the field by your customers.


Is it possible to infer that a hidden truecrypt partition is likely to be present

Plausible deniability in the context of hidden encrypted volumes is a bit of a misnomer. “Possible deniability” would be a better name. There is no way to confirm the existence of such volumes without knowing the passphrase, but there are certainly ways to infer their existence.

If the hidden volume is not inside a plain volume, the presence of completely random unoccupied space will be a red flag. If the hidden volume is inside a plain volume, less so; since TrueCrypt volumes can't be resized, it's perfectly plausible that you created a 20GB volume just for future-proofing even if you're now only using 2GB.

A simple active action to infer the existence of a hidden volume is to attempt to fill that empty-looking space. If you object or twitch, if you show any attachment to that empty-looking space, you've confirmed the suspicion that there is indeed a hidden volume. So if you have a hidden volume, you'd better be comfortable with the idea that it can be deleted at any time.

A general technique to infer the existence of an empty volume is to look for traces of access to an absent drive. Your recent document history, your command line history, your system logs might contain references to that volume, possibly (especially with respect to the system logs, or inconsistencies between the system logs and application logs) in a way that shows that the volume was not a removable drive that you don't happen to have on your person. So you'd better not access that hidden volume with your regular operating system.

You can hide a whole operating system on the hidden volume. Then what might be suspicious is when you did not use your normal operating system. So you took a computer into the country and never booted it? Suspicious! A good cover story for that would be to make your apparent operating system execute only in RAM and save nothing to disk (“it's just for web and mail, and my mail is stored on the server, this way I'm not worried about viruses”).

The very existence of hidden volumes is in fact a bit of a disservice, because you cannot easily refute their presence. The best you can do is be willing to fill your empty-looking space on demand, which may not completely alleviate any suspicion that you did have a hidden volume.

If you want to hide some data, the empty space of an apparent encrypted volume is ideal from the pure cryptography point of view, but not so much when you look at the bigger security picture. There's too much discrepancy between the apparent emptiness and the actual valuable content stored there. I would suggest hiding data inside naturally-occurring large files, such as videos; that at least gives you a reason for the space to be occupied by data that you might plausibly consider valuable.


How do you address a social engineering and or software weakness/concern in a company or organisation?

I agree that breaking in is a bad idea.

Also - you might consider that while you are a customer of the organization, going public is also of limited value, since any break-ins that occur are likely to damage you, as well.

I agree that your immediate best bet is to withdraw your affiliation and find a company with better security practices... but I'm staying within the confines of the question and assuming this isn't an option.

A good practice is to hunt down the right person and tell them about your concern.  The right person in a big organization can be very hard to find, since it is most likely NOT the guy answering the phone at customer support.  Options include:

trace through customer support management chains until you find someone with a serious enough title that he might take you seriously
research the company's executive management - in a big enough company, there should be a Chief Security Officer or similar title who has equal power to the person in charge of IT.  Often these people don't have easy to find contact information published publicly, but you might try a formal letter as a concerned customer.  Just be careful of your wording that this is a request for assistance, not a threat.
if you honestly can't through to the company, there are often government agencies that cover specific areas of law - it varies from industry to industry.  And things like the Better Business Bureau.
if the issue is truly egregious (and illegal), and the company is big enough, you could retain legal counsel and bring a class action lawsuit.

Most of these are going to take serious time.  You'll likely fail on the first few attempts to get help.  This can be a major struggle.  But if it's your data, and you don't have another option to find a better resource, this kind of battle may be the right option.

YMMV - my experience is centered in the U.S.  Can't say that other governments offer the same set of protections.


Protecting QR Code, Eddystone and NFC against spoofing

You can place a public key in your application to check the signature related to the IP address.

This signature could be placed in the QR/Edystone/NFC if there is enough room to place it (ECC certs can be small);
or you could host a service on this IP answering a challenge (the app provides a nonce, the service signs it, then the app checks the signature);
or you could provide a service over HTTPS on the IP address and check the HTTPS certificate with your public key.

You will also need a way to protect the private key. I can think of two solutions:

You can have a way to revoke the private keys deployed with the services on the IP address (for example by application update) in case a private key is abused or leaked.
The alternative is to provide the signature service by a web service you own so that you can ensure that the private key will not leak. This second scheme works like this: The application sends a challenge to the service, the service authenticates to your server and forward the challenge, your server sign the challenge then the service returns the signature to the application.


What is the point of certification authorities that are not trusted by browsers (=trusted by Root CAs)?

One theory is that, ideally, the end-user should manage his own store of trusted root CA, making an informed decision based on the published Certification Practice Statements by existing CA.

Theory and practice match only in theory, though. It is not surprising that most users cannot and will not handle such a management process, if only because it relies on highly technical concepts (not only cryptographic concepts, but also and most importantly legal concepts). Therefore, OS and browser vendors take it upon themselves to decide on a list of "default root CA" that they will put in their browsers, and will be trusted by the overwhelming majority of deployed clients. These vendors do that as part of relatively complex procedures with heavy requirements on the CA, e.g. insurance and detailed procedures in force at the CA side. (See this answer.)

Right now, CAcert is a "wannabe" CA which tries to become a "trusted CA by default", but has not yet reached wide acceptance by OS/browser vendors. Part of the problem is that procedural requirements for a secure CA have a strong financial counterpart: the physical security requirements are not cheap (you won't put a serious CA "in the cloud"; you need secured premises), and the CA must demonstrate that it has the means to keep on working for a long time, or at least to do a "clean closure" in case of cessation of activity. Money is the key. The CAcert stance of "let's give away free certificates" does not help in making enough money for that.


Binary Exploitation - How to set GID of a SUID binary using shellcode?

According to setgid(2), the syscall will fail unless the calling process is privileged:

   EPERM  The calling process is not privileged (does not have the
          CAP_SETGID capability), and gid does not match the real group
          ID or saved set-group-ID of the calling process.

Unless you are running with the correct capabilities (specifically CAP_SETGID, provided by root), you cannot change your GID to a value which is not your real or saved GID. This limitation applies to any syscall that changes the GID. The manual page on credentials(7) is extremely helpful.
You can actually see where this is done in the kernel:

SYSCALL_DEFINE1(setgid, gid_t, gid)
{
    struct user_namespace *ns = current_user_ns();
    const struct cred *old;
    struct cred *new;
    int retval;
    kgid_t kgid;

    kgid = make_kgid(ns, gid);
    if (!gid_valid(kgid))
        return -EINVAL;

    new = prepare_creds();
    if (!new)
        return -ENOMEM;
    old = current_cred();

    retval = -EPERM;
    if (ns_capable(old->user_ns, CAP_SETGID))
        new->gid = new->egid = new->sgid = new->fsgid = kgid;
    else if (gid_eq(kgid, old->gid) || gid_eq(kgid, old->sgid))
        new->egid = new->fsgid = kgid;
    else
        goto error;

    return commit_creds(new);

error:
    abort_creds(new);
    return retval;
}


If password expiration is applied, should door-lock expiration be applied too?

You asked, ‘if passwords should expire periodically, then should door locks expire periodically?’.  Well, from a false premise you can derive any conclusion!  The premise of periodic password expiration is foolish and counterproductive and damages security by imposing pointless administrivia on users for feeble defense against hypothetical attack vectors.

Of course, if you have evidence that a key has been compromised—e.g., in a photograph published by a major world newspaper—then it certainly may be prudent to change the locks, as it may be prudent to change your Facebook password after Facebook reported logging passwords in plaintext for years.


Multiple encryption subkeys on hardware smart cards

The problem is, that "stub" keys for all of the three cards are stored in your computer, and GnuPG is trying all of them.

Sadly, I'm not aware of an option to define a fixed decryption subkey, skimming through GnuPG's man page also did not reveal any.

As far as I see, the only option you have would be to remove all but the currently used encryption subkey from the keychain, and switching keychains if necessary. Be aware that before GnuPG 2.1, merging subkeys is a pain, so be sure to keep a keyring around containing all subkeys.


Is a bank's affiliate that provides services to the bank issuer required to show compliance or certification to PCI DSS

Both Visa and Mastercard require their issuing banks to only use third party service providers that are compliant with the relevant PCI standards. So it all depends on what services are being provided and therefore what the card scheme requires (because there are more PCI standards than just PCI DSS).

If the service provider is just doing stuff with  cardholder data and not providing services where other PCI standards apply (eg card personalisation) then typically the issuing bank will specify compliance with PCI DSS in the contract - the service provider would need to have an annual onside assessment by a QSA and provide a ROC to the issuer. Also Visa (I am not as familiar with the Mastercard rules) would require the bank to register the service provider with Visa and the service provider would also have to provide their RoC directly to Visa.


Gmail may be hacked - bulk spam emails being sent FROM Google apps account

It is more likely that your email address is being spoofed than your account is actually hacked, though either is a possibility.

Spoofer scenario: Because there are users from your contact list being sent emails from your account, it means that a spoofer likely got access to some of your emails and stole the recipient lists from them. They do this because spam that appears to come from someone you know is more likely to be read by the recipients. If this is the case, there's nothing that you can do to stop it though you can explain the situation to the recipients.

Hacked account scenario: It is possible that a hacker has somehow gotten access to your Google Apps account. You can check check your recent Google logins to see if you see anything suspicious. If you do find suspicious activity it may indicate specific actions need to be taken to correct the problem. Whether or not you see abnormal logins, there's no harm in being safe. Change your Google Apps password. Make it something random and definitely don't just change a character or two from your current password. You can also enable 2-factor authentication on the account. You may also want to change the password on your computers and lockscreens on your mobile devices just in case someone hacked them (seems extremely unlikely to me but changing passwords is pretty easy).


What is the benefit to using a two-pass AE scheme rather than one-pass?

(Note for clarification: that EAX is two-pass does not mean that the input message must be buffered entirely before outputting the first encrypted byte; it means that EAX involves two invocations of the underlying block cipher per data block.)

Many one-pass AE schemes, such as OCB, are patented. Also, the one-pass schemes are also often "one-and-a-half-pass": they imply per input data block one block cipher operation, and one extra operation which is usually said to be "fast" but not necessarily that fast, depending on the context. For instance, on an embedded system with a 32-bit ARM CPU and low RAM, GCM tends to be slower than EAX, although GCM implies only one AES block encryption per 16 bytes of input: GCM also involves a multiplication in the finite field GF(2128), which can be made fast with the help of 64-bit registers or big precomputed tables, both of which lacking on many embedded systems.


Can I redact by converting PDF to TIFF and back?

If the scanned documents don't have passed an OCR process, and come along without sensitive metadata, rendering to TIFF, properly changing the pixels to be redacted to a uniform black (or any other color), flattening the TIFF, and writing it back as a PDF would be sufficient. This is because you create a completely new document. If it had metadata, that metadata would concern your process, and not previous ones.

Depending on the requirements for the redacted document, you could run OCR over it, and/or add your custom metadata. But, again, that would be done under your control.

Ideally, the scans would come in as TIFF, which you process, and only then create the PDF. This would simplify the workflow.

In any case, you would need an image editor which understands TIFF and PDF, and do the redaction in the image editor.


EternalBlue exploit doesn't work against windows 8

Just because it doesn't work for you doesn't mean it's safe. You should patch your box.

If you are running an unpatched Windows 8 box, don't expect to be safe.

There's a lot of reasons why it may not work if your box is unpatched:

You may be attempting the wrong exploit packages. Would you trust random GitHub code without first auditing it?
You may not be able to spawn a reverse shell due to firewall policies, and would need a bind shell, or the other way around. Maybe you can't do either, but RDP is open; in that case, use windows/adduser as a payload. There's a lot of things to consider here - you will need to enumerate your box.
You may need the right target, encoding, to target the right architecture, process, etc... basically, you might not be using the right settings.

We can't really help you without enough details. Did you patch? If so, you should be fine. However, I would personally just disable SMB 1.0 because it's a dumpster fire.


What does my iPhone see/track when connected to my macbook PC?

Your iPhone won't directly see what you did on your mac while you're charging it. But there's a catch: your browsing history might be synced via the cloud. If:

You were browsing using Safari
You were not browsing in "incognito"
You have iCloud sync activated
You're logged on your iPhone with the same Apple user as the one used on your mac

I'm pointing this out in case you used your personal Apple user on the iPhone e.g. to download apps without creating a new one.


As far as security goes, there's no specific standard that I'm aware of. Smart ticketing systems are a varied bunch, but they usually consist of:

Some sort of passenger identifier, e.g. an RFID / NFC card or device.
A point-of-sale (PoS) device, such as a scanner on a bus or in a station.
A communications link between the PoS and the back-office.
A back-office system which processes the transactions, maintains balance and customer information, and interfaces with the payment gateway.

Most importantly, card details are usually taken ahead of time, and are usually stored only in the back-end system.

The specific configuration is largely dependent upon the transport type. While a metropolitan bus service could operate a 3G cellular link back to the office, a cross-country train may have more difficulty in rural areas where cell towers are few and far between.

The normal mechanism that I've seen is that the list of valid card IDs is synced onto all PoS systems periodically (e.g. via WiFi at a station) so that individual cards can be identified as "valid" without having to call home every time someone swipes in. Each transaction is locally cached and then transmitted when a connection is available.

The security of the actual communications is entirely up to the implementation. It may rely entirely upon data-link layer encryption (e.g. WPA2), transport layer security (e.g. TLS), or may implement its own application layer security.

Of course, in the case of systems where contactless payments are performed at the PoS, the PAN may well be transmitted, and as such the communications (and PoS device) will become part of the PCI domain.


Depending on your library you should be able to configure your parser to ignore entities.


Documentation for GDPR best practices for partially masking email addresses

There is no official guidance because this is not a GDPR enforced requirement. GDPR does not regulate specific security measures beyond making recommendations about what you should consider. Since you consider doing something like that, you in theory should do a Data Protection Impact Assessment to identify levels of risk may be associated with your situation and then decide on how to proceed.

Generally, using username@provider.com turned into u******e@provider.com is perfectly fine for most cases, since the domain name does not identify a person. However, if your specific intent is to also protect domain names (which is a thing again determinable by doing a Data Protection Impact Assessment), then you could extend the protection to a format covering also the domain: u******e@p******r.com .


How is the strength of a DDoS attack measured?

It sometimes is hard to measure the exact size of a DDoS attack. When links get saturated you can't tell from the victim's perspective how much more traffic was sent to your network than your network's links could handle. If your network has a 100Gbps uplink, you can't tell the difference between a 100Gbps attack and a 1.2Tbps attack from within your network, since the effect is the same: the link is saturated.

The only place you can check that is at the upstream networks of the network under attack. But it can be the case, especially with enormous attacks as on Dyn, that even links on their network get saturated, so you'd have to check statistics for traffic towards the victim of the DDoS on their upstream networks as well.

Calculating the exact size of the attack may get even more complex when networks between the attackers and the victim are filtering some of the DDoS traffic. Some network automatically filter or rate limit known bad outbound traffic from their network, so it never even reaches the network under attack or its upstreams.

To sum it up: it's hard to give an exact measurement of the size of a (large) DDoS attack, but by aggregating statistics of the network under attack and its upstreams you can make an educated guess.


Results for """"

If you see this in the rendered page, the page is not vulnerable to XSS, because the < and > characters are correctly escaped. The source would look like this:

  Results for ""&lt;span&gt;&lt;/span&gt;""

As you can see your HTML tags don't end up as HTML tags in the source, so it is not possible to inject tags into the HTML.

Now, it seems that your site also does some sanitation on the input. It removes some tags and alters the javascript: URL. This is not a sufficient method to protect against XSS. It is pretty hard to write an XSS filter correctly, and most of the time such filters can be bypassed by using some combination of tags and attributes.

The correct way to protect against XSS is to HTML encode on output.


How much detail to publicise when a software vendor patches and issues an advisory?

The "normal" way of doing things is:

Whoever finds out the flaw contacts the vendor.
Vendor makes the patch, and publishes it, pushing it to customers with a vague but scary description ("fixes a flaw allowing for remote code execution").
A few weeks later, details are published. If all went well, the initial discoverer makes the publication, in full agreement with the vendor, so that due credits are attributed; and the vendor adds a link to the publication details in his own documentation.

For instance, this is what happened with the SSL-related flaw dubbed "CRIME": browser vendors were warned several weeks in advance, and pushed patches. Occasionally, the vague description can be enough for some people to guess what is happening a few days before actual publication. The dance is a matter of delicacy, especially with opensource software, because patch source code is often quite revealing about the exact nature of the issue.

One psychological side of the issue is that vulnerability hunters are a tough crowd who may react, sometimes, in somewhat heated emotional ways, if they feel that vendors don't react appropriately or fast enough. Software vendors would usually prefer to keep flaws secret, but if they have to accept publication, then, at least, they really prefer to have some advance warning. The "due credits for prior warning" barter is an arrangement which has a high probability of convincing most bug-hunters not to push the exploit right away on public channels, so software vendors will support this "normal way".

Ultimately, when the dust has settled, all details should be published, because full disclosure is a great foundation for trust.


Is inputting a password over a phone secure

Is this a safe practice?

No, absolutely not.

Unlike internet traffic over HTTPS, phone lines are not encrypyted. In theory, nothing is preventing HTTPS-style encryption, but the problem is that both devices need to be able to do that. Normal phones just can't do it. And unlike HTTPS, there is no single big solution that the whole world knows and accepts.

Note that GSM and later mobile phone protocols have some encryption, but a) it is not that secure, and b) in the usual case, the signal to the base station is encrypted, and then from the base station on it's plaintext again.

Also note that some few of the "big" lines between countries etc. are encrypted (ie. phone->telecom1 not encrypted, telecom1->telecom2 encrypted, telcom2->phone not encrypted), but sadly that's rather seldom.

What that means for practice? Either crack GSM, or more easy set up your own base station, or even more easy (but a bit dirty) dig a hole to get to a major transport cable. (Or, if you're a diva like some certain government agency who doesn't want to get dirty, ask the biggest phone/internet node on the continent to get own rooms in the network center.). Being a telecom employee is nice too....

The only positive aspect might be that most attackers focus on the internet and related devices (computers, mobile phones, ...), instead of old phone connections.

  Specifically, is this less secure than inputting my password on their
  website?

Sure

  As keypad buttons don't map 1:1 with ASCII characters

So what? Anyone listening for pressed phone keys knows that and can easily convert it


Should the access to nearby friends location data and last active time be rate limited?

As of today there haven't been any efforts from facebook to restrict such APIs, mostly because it'll not let people build legitimate products using such features or APIs.

In past people have already developed tools that profile user's activity using such 'leakages'. One prominent tool released last year is fb-sleep-stats. This tools polls user's messenger activity status every 10 minutes and then graphs their sleep patterns.


Is 2-factor authentication for webmail useful when e-mail checking through other methods is without 2fa?

The app based passwords used only allow certain types of connections. Yes they could access your email if it was compromised, but you should only be using it over a secure channel (Such as imap with ssl) so it's not likely - unless your endpoint is compromised, but then you have bigger issues.

App based passwords do not tend to allow logging into web mail and account management. This means an attacker cannot make account level changes such as password changes.


Will disabling "symlink" in PHP.ini prevent attackers from attacking other websites?

Symbolic links is used for creating shortcuts in Linux.
If an attacker gains access to any single site on your server, he can easily
create a symbolic link to / directory & then putting the document root
afterwards it. Now the attacker can easily read your sensitive files.

You can protect it by:

Change the permission of /bin/ln to 400.

Locate php.ini by command- “locate php.ini” (without quotes). Edit the main
php.ini & disable symlink & proc_open.

If you have a shared host, & it is vulnerable to symlink, then change the
permission of your configuration files to 400.

Turn PHP safe_mode ON


To my knowledge, Azure Resource Manager PowerShell scripts use the same permissions as the Azure portal, so no, you cannot prevent a user from running a PowerShell commandlet and still let them perform the same actions on the Azure portal.   This link provides more information about managing Windows Azure Permissions


Finding security consultant for doing in-depth code review?

Code review can be an expensive use of a consultants time and therefore your budget, to ensure you are getting value for money you could look to do the following;

Triage the code you require to be reviewed. This way you may find that you can focus on code that completes specific roles such as authorisation / session management / specific business logic etc. that you are worried about. If you then have budget left over you can move on to other less critical code areas.
Estimate the time and effort required As a very rough estimate you can use the 1k lines of code = one full day of review (not including reporting). Different languages and code complexity will change this, but it provides a good starting point when looking at budget requirements.
Automation as an aid Automated code scanning has its place, but only adds value if the consultant knows how to configure the tool and use it as an aid in their manual review. Using a blended automated-manual approach can speed the engagement up and lead to a reduced cost. The consultant should be skilled enough in the language being reviewed to understand the security issues and to remove any false-positives as well as insure no false-negatives get through.
Threat Model the application If you can understand the business logic and how attackers can interact with your application to a level that enables you to model potential attack vectors, then this will help define a more specific and focused code review. This level of detail can then be passed on to the consultant to ensure that they are aware of how the application works and this will enable them to provide tailored advice and guidance rather than a generic - here are some risks.
Place the findings in to context of the application At the end of the day you will need to make a call on which issues to fix and in what order of priority. Challenge the consultant to make clear recommendations and to provide evidence to help understand if findings from the code review are actually a threat - i.e. the code found to be vulnerable is at the back-end and their is no route for user interaction then this is a lower risk than if the vulnerable code is in the main authorisation code presented to the end user. This should reduce time internally and therefore become a cost saving that can be offset against the cost of the code review.


Is exposing exception information in web service a security risk?

The API should not expose any internal information, i.e stack traces or similar. As you really noticed they might leak information which might be used to attack the implementation.

Moreover they are usually only relevant for the developer of the API and not the user of the API. These users expect proper error messages anyway and not some strange message where they would need to ask the API developer first what this means and the developer would need to look at the source code. So this might be less a security issue but more a usability problem of the API if you just throw the stack trace to the user instead of something meaningful for the user.


What's the purpose? Strange login attemps "sshd[***] Received disconnect from **.**.**.**: 11: Bye Bye [preauth]"

This error rises from a fatal error in the authentication process (see monitor.c of OpenSSH versions 6.1p1+).

It is likely that the attacker is using some custom code to brute-force the server which is ending up in malformed authentication requests being sent, resulting in the server killing the connection. So from the code it appears they are in fact trying to login, but the server doesn't like how they're attempting that.

As such, these log entries aren't anything to worry about unless you think you are likely to be a targeted victim for any reason (in which case you should be taking extra precautions such as refusing password-based logins).

In any case, I suggest you install the simple fail2ban program if you haven't already which will significantly hinder cookie-cutter brute-force authentication attempts.


Risk management with software code analysis

There is no reason it shouldn't, in fact, that's a great way to do an initial check.  The reason it isn't specifically listed is because the pen testing and manual analysis should do a much better job than an automated analysis (and may well include one as part of the review.)  The point is that automated testing alone isn't sufficient.


What steps do Gmail, Yahoo! Mail, and Hotmail take to prevent eavesdropping on email?

An SMTP session between two mail servers may be encrypted, but only if both ends support it and if both ends choose to use it.  So if you're sending mail from Gmail to example.net, then Google could only encrypt if example.net was ready and willing.  For this reason, you cannot trust email to be even moderately secure at the transport layer. (The only safe end-to-end method is to encrypt your email using S/MIME or PGP, but the people you're exchanging email with need to be on board too... just like the mail servers).

As to whether the big three are performing opportunistic STARTTLS, I haven't seen any evidence of it, but I spend less time reading my mail server logs than I used to.  And if they are, they're still only half of every SMTP connection they make, and cannot guarantee the use of encryption.

Update:

I just banner tested MX hosts for gmail.com, yahoo.com, and hotmail.com.  Only gmail advertises STARTTLS, which is to say, only gmail would be willing to encrypt the SMTP session if the other party wanted to.

I tested gmail outbound by sending mail to a server I own and watching the wire; Google does indeed take advantage of STARTTLS if it is offered and encrypts the SMTP transaction when a gmail user is sending mail.  Props to Google.

So as far as "sending" email encryption goes: Google 1, Yahoo 0, Microsoft 0.

As per the comments below, if you want to test these yourself, it's very simple:

Determine the MX hosts (Mail eXchangers) for the domain
Telnet to port 25 on one of them
Type in "ehlo yourhostname.domain.com"
If you don't see "250-STARTTLS" as one of the responses, they don't support opportunistic encryption.

Like this:

$ host -t mx yahoo.com
yahoo.com mail is handled by 1 mta5.am0.yahoodns.net.
yahoo.com mail is handled by 1 mta7.am0.yahoodns.net.
yahoo.com mail is handled by 1 mta6.am0.yahoodns.net.
$ telnet mta5.am0.yahoodns.net 25
Trying 66.196.118.35...
Connected to mta5.am0.yahoodns.net.
Escape character is '^]'.
220 mta1315.mail.bf1.yahoo.com ESMTP YSmtpProxy service ready
ehlo myhost.linode.com
250-mta1315.mail.bf1.yahoo.com
250-8BITMIME
250-SIZE 41943040
250 PIPELINING
quit
221 mta1315.mail.bf1.yahoo.com
Connection closed by foreign host.
$

As a side note, Yahoo will close the connection if you don't ehlo right away.  I had to cut & paste my ehlo because typing it in took too long.

MORE UPDATE:

As of January 2014, Yahoo is now encrypting - I just tested (as above) and verified.  However, both The Register and Computerworld are reporting that the intracacies of SSL setup (such as Perfect Forward Secrecy) leave a lot to be desired as implemented by Yahoo.

EVEN MORER UPDATE:

Google is now including SMTP encryption data in their Transparency Report Safer Email section.  They're sharing their data about who else is willing to encrypt, and you can look at the top numbers as well as query individual domains.

Addendum:

@SlashNetwork points out that it is possible to configure a mail server to require that TLS be negotiated before exchanging mail.  This is true, but to quote the Postfix documentation:

  You can ENFORCE the use of TLS, so that the Postfix SMTP server
  announces STARTTLS and accepts no mail without TLS encryption, by
  setting "smtpd_tls_security_level = encrypt". According to RFC 2487
  this MUST NOT be applied in case of a publicly-referenced Postfix SMTP
  server. This option is off by default and should only seldom be used.

Now, the world is full of implementations that violate the RFCs, but this sort of thing - e.g., something that may break routine required functionality like accepting bounces and mail for the postmaster - is probably more likely to have negative consequences.

A better solution which mail gateways often allow is the imposition of TLS requirements on a per-domain policy basis.  For example, it is usually possible to say "Require TLS with a valid Certificate signed by Entrust when talking to example.com".  This is usually implemented between organizations that are part of the same parent company but have different infrastructure (think: acquisitions) or organizations with a business relationship (think: ACME, Inc., and their outsourced support call center company).  This has the advantage of ensuring that specific subsets of mail that you care about get encrypted, but doesn't break the open  (accept from anyone by default) architecture of SMTP email.

Addendum++

Google has announced the gmail will percolate information about the security if the mail path out to the reader.  So these behind-the-scenes encryption steps will be brought to the notice of the user a little bit more.

(Probably still doesn't care about the certificate provenance; just an indicator of encryption of bits).


Why is it a terrible idea to implement restrictive measures in .bashrc?

There are a number of reasons this is a bad idea.

First and foremost being that bash, fundamentally, is written to facilitate users doing whatever they want to do. It was written to make it easy to do anything you'd want to do a vast number of different ways, and as a result it's possible to do most things a vast number of different ways. It was not written with access controls in mind, and as a result it lacks access controls. As a result, adding access controls on top of it, and making certain tasks impossible within it, is a bit like trying to use a bulldozer for needlepoint; maybe not impossible, but very, very difficult.

So, for example, any command run from .bashrc can be interrupted, backgrounded, or killed if the user (or more likely a script that the user wrote) is fast enough (by sending ^C or ^Z). On the command line, users can unset variables, they can open subshells, they can specify direct paths to executables (many of which are in predictable locations), and they can even send things over the network even if you don't have any network-accessible applications available to them, because they can open tcp streams directly from bash.

Now, this is a known issue, and it's why rbash was developed. But even rbash is not a turnkey solution, and at the end of the day even it is quite lax:

  These restrictions are enforced after any startup files are read.

  When a command that is found to be a shell script is executed (see Shell Scripts), rbash >turns off any restrictions in the shell spawned to execute the script.

And then, of course, there's the fact that you must constantly make sure your version of bash is up to date, and that your kernel is up to date and that you're using an explicit whitelisting approach and carefully vetting each application you allow. It's a pretty Herculean task, and most of the time there is a better / simpler way to accomplish what you want to accomplish.

If you have a particular security setup in mind, and you were considering using .bashrc, then:

Do some more research around the internet (Google and DuckDuckGo are both quite helpful for this, although the site you're currently reading is one of the best resources you'll find), and once you have some alternatives in mind and some research to back each,
Ask about your setup here! Read the site FAQ, and try to ensure your question isn't a duplicate, first. But apart from that, this is where you'd want to ask the questions you're having.


Do browsers still send cookies if I choose to visit an unsafe site warned by browsers?

... visit an unsafe site warned by browsers?

First, these HTTPS related warnings are NOT about the site being safe or not. HTTPS says nothing about the actually security or safety of a site but only cares about protecting the communication between the browser and the site.

These warnings inform you that the communication MIGHT not be properly protected since the certificate does not match the expectations. You should only bypass the warning if you are sure that the site is just wrongly configured, i.e. that the certificate might not match the browsers expectation but it matches your expectation.

Based on this the browser will then assume that the communication is properly protected since the certificate matches what the user expected and will then proceed as normal, including exchanging cookies with this site.


Is it possible to make cracking a password pointless to an attacker with database access?

TL;DR: The answer is no. A user cannot be stopped from reusing the given random password on other sites, so a text based password will always have value to an attacker. This is true for all sites with usernames, and passwords.

Enforcing random passwords rarely works: it makes your users (customers ?) go away. Suggesting random passwords, and offering a generation tool, are good ideas, as long as they are not made compulsory. However, even if you succeed in enticing your users into using random-generated passwords for your site, you cannot prevent them from using the same passwords on another site. It can be expected that after having made the effort of remembering a random password, a substantial proportion of users will find it smart to reuse that effort, i.e. reuse the very same password elsewhere.

This is a very general property: as long as a user "knows" his password (and he must certainly know it in order to type it), then he can reuse that password in other systems that are outside of your reach. You cannot do anything about it, except trying to explain to users why this is not a good idea.

As for two-factor authentication: when it is there, it is for a reason, i.e. because one factor was not enough. If an attacker cracked a user password, then the user's two factors shrunk to one factor only. If one factor is not enough, then it is not enough. Or, said otherwise, if users authenticate with a password and a mobile phone, and cracking the password is not a problem, then why bother with passwords at all ? Just use the phone.


Can a self-root certificate spy on me without a vpn or proxy on iOS?

Certificates are used to verify the identity of the remote end of a connection. You can think of them like picture IDs or driver’s licenses.

A certificate is not an active thing. Certificates cannot spy on anyone.

Like a driver’s license, a certificate shouldn’t be easy to counterfeit. If a certificate is issued by a reputable service, it can’t be.

But if you self-sign it, you aren’t a reputable service. You may trust it, but nobody else should.

A self-signed certificate is fine for protecting your own private communications, but is worthless to prove your server’s identity to anyone else.


Can authentication in social networks through VPN defeat the purpose of the latter?

As noted, VPN tunnels permit secure and private communication through untrusted networks. VPN "anonymity" services, fundamentally proxies on sticks, can also provide limited anonymity.

However, using a particular VPN service for authenticated social-network activity irrevocably destroys whatever anonymity it had provided for the user. All usage of that VPN service from the user's ISP-assigned IP address is affected. Getting a new account doesn't help, given linkage via IP address and payment method. To the extent that the VPN provider retains logs, metadata for all prior usage is also deanonymized (even if content is protected via PFS).

If OP wants both "anonymous" and true-name authenticated activity protected by VPNs, she needs to use two different VPN services, and should carefully compartmentalize her activity between them.


This code is very bad.  If you're copying it from elsewhere, you need to stop doing so.  If you're writing it yourself, well, you shouldn't use it in any system that's actually security critical—you should seek expert assistance if that's the goal.  The only justifiable purpose to code like this is as an educational exercise.

Let's dive in to the problems.

Use of obsolete and insecure DES cipher

DES is a 1970s cipher with 56-bit keys.  That is much too small a keyspace for security; brute force search of DES keys was already demonstrated over 20 years ago.

Hardcoded cryptographic key?

  I have found a string called key =  ucnTRFY<jhvbu,fwy8\u00a3329+3yrwiefDY#FGVoD@IOHa?widNCD(ZH3*82YU9%Fjpo

If this is a string constant in a real-world program, then that's really terrible.  Programs should never hardcode cryptographic keys; they should read them at runtime from secure storage.  The only scenario where it's acceptable to have a hardcoded key like that is in a trivial demo program.

Even if the string comes from a file instead of being hardcoded, the fact that you're able to read it already should make you wonder whether it was adequately protected.  If it's a secret key, how come I'm reading it on the interwebs?

Obfuscated/convoluted key deserialization

DES takes its key as a byte[8].  The program computes that byte[8] from the key string in a really convoluted manner:

private SecretKey getKey() {
    byte[] desKeyData = new byte[8];
    for (int i = 0; i < 7; ++i) {
        int j = i * 3;
        desKeyData[i] = (byte)(key.charAt(j) ^ key.charAt(j + 2));
    }
    return new SecretKeySpec(desKeyData, "DES");
}

This doesn't do anything other than make the code needlessly complicated.  A well-written real-world program would obtain the desKeyData by reading it directly from a binary file or by deserializing it from a string representation of a binary array (e.g. hexadecimal digits, Base64).

Passwords should not be encrypted

The code is encrypting a password.  This is an insecure method of password storage.  See the top answer to of our top passwords questions, "How to securely hash passwords?".  That should answer your question about bcrypt as well.

Use of insecure cipher mode

This line of code:

Cipher cipher = Cipher.getInstance("DES");

...initializes the Cipher object in ECB ("electronic codebook") mode.  This is almost without an exception a bad idea.

Unauthenticated encryption

As a general rule, you should only use ciphers that protect both the authenticity and confidentiality of the messages.  Modern ciphers protect not only against an attacker reading the content of the messages, but also against forgeries.

ECB mode doesn't do that.  And you'll find lots of example code using modes like CBC that don't do so either.

Use of numeric literal instead of mode constant

This line is needlessly hard to read:

cipher.init(1, key);

It should be this:

cipher.init(Cipher.ENCRYPT_MODE, key);

Bad exception handling

Lots of lines like these:

catch (UnsupportedEncodingException ex) {
   // empty catch block
}

Or these:

catch (BadPaddingException e) {
    logger.error((Object)e);
}
return password;

Security-critical code needs to be exceptionally clean.  If anything fails you should generally assume the worst and cause the whole operation to fail, not swallow an exception and keep going like nothing wrong happened.

(Also, that upcast to Object in the second example is trivial and can be removed.)

Code discipline (method contracts, state avoidance, type safety)

All that logic with the doEncryption and encrypted boolean fields makes me nervous.  It sounds like this code is inside a class whose objects can be in four states:

Contains encrypted data, does encryption/decryption when requested to
Contains unencrypted data, does encryption/decryption when requested to
Contains encrypted data, ignores encryption/decryption requests
Contains unecrypted data, ignores encryption/decryption requests

...and the class's methods and external clients then have to be mindful about its state so as not to expose an unencrypted password by mistake.  The following bit of code in the encrypt() method is the most symptomatic example:

if (!doEncryption) {
    return encryptedBytes;
}

So if I'm using this class and I call encrypt(mySuperSecretData) method, it might actually not encrypt it at all?  What is the contract of the class and the methods?  Is that contract really confusing or allow for the class's clients to easily misuse it?

Why have such a complicated class with these many self-defeating options?  Maybe instead you should have separate types PlaintextPassword and ScrambledPassword so that when you try to pass a PlaintextPassword to a piece of code that expects a ScrambledPassword, it become an error at compilation time and not a security failure.  With careful design and discipline you can gain much greater confidence that the program will not expose sensitive data by mistake.

This is part of the same theme as the previous point: security-critical code needs to be exceptionally clean.  If I have to pause and read carefully the if statements and a || b conditions across those two methods to figure out whether there's a risk that they were incorrectly written and will reveal secret information in some scenarios, then I have to ask whether all that logic can just be removed.

Conclusion

This is the wrong level from which to approach cryptography.  If you're interested in practical uses of cryptography, you should seek out a good, high-level cryptographic library that offers an easy interface, with good, safe default choices made for you an really good documentation that you can count on to tell you exactly how to use it.

The default Java cryptography API isn't that. Java has lots of cryptography support, but it all tends to be terribly hard and dangerous to use.  It requires a lot of knowledge to use it safely, and that knowledge cannot be acquired by tinkering around with random code samples that you find somewhere—because if they're not just flat-out wrong, they're at least often outdated and no longer reflect best practices.  Learning to use Java cryptography APIs generally requires reading third party materials that allow you to understand sound cryptography fundamentals.


Absent certain exploit mitigations that intentionally randomize the process address space to defeat memory corruption attacks, a program's addresses will be highly predictable every time it runs. In other words, once you find a working exploit, it should work on every machine running the exact same version of the software (assuming there's no address space layout randomization). It does need to be an exact match - different architectures (like x86 vs. amd64 vs. ARM) won't match, nor will builds from the same source code but targeting different operating systems or compiled with different compiler flags. However, in practice, most software is distributed as a pre-built binary, so everybody on a given platform is in fact running the same version.

In some cases, the memory layout that you're targeting will be different depending on how the program was used prior to your exploit occurring. This isn't a problem in software where you control how it launches, but for many long-running servers it can be difficult to anticipate the software's current state when you attack it. One option is to just corrupt memory anyhow; the program will almost certainly crash (itself an exploitable issue, for denial of service) but often a watchdog will launch it again. Then, you attack the newly-launched process. Another option is to make your exploit robust against slightly missing the start of the shellcode/ROP chain. One way to do this is what's called a "NOP sled", where you put as many NOP (no-op) instructions as possible before your payload; when you do that, you only need to get the instruction pointer to land somewhere in the NOPs (or at the first part of the actual shellcode), and then the processor just "sleds" down the NOPs into your payload.

Defeating ASLR and other mitigations is a different topic, and potentially quite difficult.


What does "exploit price" on vuldb.com means?

Yes, it means that in the exploit market that kind of exploit can be sold and bought for something in that range (e.g. $25k-$50k). That website doesn't specifically talk about black market:

  The ongoing observation of the exploit market structure helps to collect current prices.

but, if you don't report vulnerabilities to bug bounties, the market you'll find is somewhat gray, if not definitely black, as the legality of selling exploits to a third party is dubious.

A well-known company in this sector, Zerodium, has published its payout ranges for different types of exploits: https://zerodium.com/program.html. There is also a famous 2012 Forbes article on the topic.

It is also very likely that vuldb.com crawls black market websites, in order to find more accurate information on the prices. However, there are probably market areas which cannot be easily found, such as the three/four-letter agency market (i.e. worldwide intelligence agencies, such as the NSA). It has been speculated that prices in those areas are much higher than the ones typical of the "standard" black market.


Under constant ddos, even after switching 3 differnet routers?

Based on the fact you claim to be getting knocked offline even though you have moved several times, I would guess that you linked your Skype account or some other service that exposes your IP address on your twitch account, which the attacker is using to find your IP.


how to get address of PE section to jump in while backdooring PE binary

There are three addressing concepts you need here. RVAs, VAs, and offsets.

Relative virtual addresses (RVAs) are addresses into virtual memory. They are configured via the PE's header. If you look at a PE file's section table, you might see something like this:

In this table you can see that the .text section starts at a raw address (offset) of 00000400 and has a size of 00002200. Its virtual address (VA) is 00001000.

Next, if you look into the optional header (PE header) you'll find an entry called ImageBase:

This sets the base RVA for the executable. You add this to a VA to get the RVA.

Let's run through an example: translating an offset of 0x2740 to an RVA. First we walk the section table to find which section that offset is in. We can see that .text starts at 0x400 and is 0x2200 bytes long, meaning it ends at 0x25FF. Next there's .rdata, which starts at 0x2600 and is 0xA00 bytes long. Our address sits within this section! So we subtract the raw address of the section (the base of the section) from our offset of 0x2740, to give us the raw offset into that section. That gives us 0x140. Next, we add this to the base virtual address of the section, which is 0x4000, to give us 0x4140.This is our virtual address (VA). Then we add the process image base, 0x00400000, to that to get us our RVA: 0x00404140.

My guess is that if you look at your target process, you'll find that the 1C0000 "gap" between the values you're looking at come from the ImageBase value and the difference between the virtual and raw addresses in the .text section.


Why there is a signed hash in Certificate request (.csr file)?

From the RFC, note 2:

  Note 2 - The signature on the certification request prevents an
     entity from requesting a certificate with another party's public key.
     Such an attack would give the entity the minor ability to pretend to
     be the originator of any message signed by the other party.  This
     attack is significant only if the entity does not know the message
     being signed and the signed part of the message does not identify the
     signer.  The entity would still not be able to decrypt messages
     intended for the other party, of course.


Why don't security systems prevent against password incrementing?

I guess this is wilde guessing which is not worth it. Should you only identify numbers?  How may? Why not identify characters? If I am setting my password to be "secret10", the system would save Hash("secret10") as my password hash and Hash("secret11"), Hash("secret12")... to be hashes, which I would not be allowed to use in future. But this system already breaks when I set my next password to "Secret11". The system is not capable of identifying the changed upper case! Comparing hashes with even the slightes logic is not possible. Since even the slightest change will break the Hash. And if you want to design a secure system based on passwords, it is more impartant to use hashes than to check for changes in the passwords.


How to create a secure password for a Java keystore?

A password with 256 bits of entropy is more than enough to withstand even the most well-resourced brute-force attacks.  See https://crypto.stackexchange.com/questions/1145/how-much-would-it-cost-in-u-s-dollars-to-brute-force-a-256-bit-key-in-a-year for some interesting reading on this subject.
The command below will produce a random password with 256 bits of entropy:
head /dev/urandom | sha256sum


Is it safe to open a server application on the internal network to the public internet

It is not safe.
Simply port forwarding internet traffic to an application running in your local network essentially exposes your full internal network to some attacker in case of a bug in the application. And bugs are likely. If the server application is instead located at some hosting provider on the public internet it will not have access to your internal network.
If it is only about testing your application from outside or providing access to a few selected users you should at least add strong  authentication with some proven setups, for example by using nginx as a reverse proxy. Or you could use solutions like ngrok for a more limited exposure of your internal application to the internet. You could also put the application into some container or VM with appropriate firewall rules so that it cannot access the internal network.


Safety of Password Hashing Using bcrypt Done on Client Side

The issue is that your hash now essentially becomes your password. If your database of hashes gets stolen, they don't need to worry about brute-forcing any of the hashes, because that's all you need to send now to authenticate.


Can the human brain generate cryptographically secure random numbers?

It's plausible that entropy could somehow be generated from brain processes, but doing it directly (e.g., "think of a random number") is, in my opinion, pretty easy to discount.

In a random sequence of bits, the value of any given bit is independent of all other bits in the sequence. However, if you ask a person to generate a random sequence of bits, there's no way to isolate the generation of a bit from the knowledge of which bits preceded it.


truststore and intermediate certificates

Contact your third party and ask them to configure their server/service to send the intermediate certificate(s) as per RFC 5246 Section 7.4.2. Specifically, the section marked certificate_list which is sent as part of the Server Hello message.

  This is a sequence (chain) of certificates.  The sender's
        certificate MUST come first in the list.  Each following
        certificate MUST directly certify the one preceding it.  Because
        certificate validation requires that root keys be distributed
        independently, the self-signed certificate that specifies the root
        certificate authority MAY be omitted from the chain, under the
        assumption that the remote end must already possess it in order to
        validate it in any case.

If the intermediate certificate(s) change, it's up to the sender to update their service to send the new certificate.  That is, it is not up to all the recipients to realise that things have broken, find the replacement certificates, then install them on all their relying parties.

There is also the option for the operators of the service to use certificates which contain the AIA extension (RFC 5280 Section 4.2.2.1 - id-ad-caIssuers's accessLocation field) which can contain an URL which points to a repository (HTTP more than likely) that contains the issuer certificate for download.  This requires both the extension to be present (that's up to the issuing CA) AND your app to check it (that's up to your developers).  This extension is a Microsoftism, added to compensate for substandard service administration - the RFC is quite clear about what should happen.


Second one is definitely better compared to the first. But.....i do not know which kind of users you are dealing with because for the average computer user, more people are aware of VPNs and program  to hide their identity more than being able to change headers.

In my opinion, i think headers could be more reliable because for the average user, it is easier to just download a VPN program. I do think storing both though is better than not if you really need to know the IP.

Also just keep in mind that both the header and remote could not be authenticate if the user knows what they are doing as far as hiding their identity.

There is a lot more information you can collect to about the user to identify them but like i said it all depends on who your users are and what you are trying to do with that information.

Just some things to think about!


How do I use a TPM to protect my BIOS/EFI from "remote" attacks

You are mixing up two technologies here it seems.

First, there is UEFI and its Secure Boot feature. Secure Boot can be used to assure that your boot loader and your OS kernel are not tampered with. In order to do so, your boot loader and kernel need to be signed digitally and your UEFI configuration must contain the certificates/signatures needed to verify the signatures. Windows 8 on ARM platforms uses UEFI to effectively prevent other OSs from being installed. UEFI, however, does not offer any real protection against attacks on firmware level.

Now for the TPM: The TPM is a passive hardware chip that is (amongst other things) used to store measurements (hash values) of e.g. software in a tamper resistant manner and to make those measurements available for reporting.
Mainboards that ship with a TPM have special requirements to their firmware. First, they have a tiny piece of special firmware called Core Root of Trust for Measurement (CRTM). The CRTM is executed first during boot and stores measurements of itself and of the next piece of firmware (BIOS or UEFI) before handing over control to it. The next piece of firmware would typically measure the boot loader which in turn would measure the OS kernel and so on up to application level (in detail the measurement process is more complicated of course). Most boot loaders and OSs, however, do not use the TPM this way. Anyway, if you have a TPM on your Mainboard, you can be sure it measures your firmware.

What can you do with those measurements? BitLocker e.g. uses Sealing to bind the keys needed to decrypt your HD to those measurements. That means, your HD keys can not be used, if malware corrupts your firmware. So, on Windows you can use BitLocker to protect against tampering of your firmware. I am not aware of something similar for Linux (though something might exist). You could however, use a Trusted Network Connect (TNC) enabled Radius server and a TNC enabled wpasupplicant to verify the measurements remotely.


Will setting a BIOS Password Protect the TPM?

Okay, so, after some more searching I solved my problem:

Bitlocker does allow you to use an actual password (but they call it a PIN) - can't be more than 20 characters, but that's still pretty good.

RUN > gpedit.msc
Select: Administrative Templates > Windows Components > Bitlocker Drive Encryption > Operating System Drives

Double click "Require additional authentication at startup"
Select ENABLE at the top
Under "Configure TPM and Startup PIN" drop-down menu, select "Require Startup PIN with TPM" > Click Okay

Double click "Allow Enhanced PINs for Startup"
Select "Enabled" > Click Okay

Run CMD as an Administrator

Enter: manage-bde -protectors -add c: tp

*Change C to whatever the drive letter your system drive is

Now, enter the password you want, can be letters, numbers, symbols, uppercase, lowercase, etc.  20 characters max.

This worked for me and now I'm happy to be secured behind a 20 character actual password and not just 20 numbers.

This data should really be more available from Windows to make it more user-friendly, so hopefully this helps you.


Use of openssl could be a weak point in an Android App?

Obfuscation is "required" when either of the three following situations applies:

The application does something which is inherently weak such as embedding a secret value in the source code.
The application designer wants to "feel safe", and is sufficiently incompetent at cryptography so that obfuscation provides that feeling (ignorance is bliss).
The application vendor wants to protect his "intellectual property". Code obfuscation will not ultimately prevent copiers from understanding how the code work, but it may delay their reverse-engineering efforts by a few days (not much more than that); more importantly, obfuscation is a way to make it obvious that the code contents are not meant for external inspection, which helps in obtaining legal qualification of forbidden reverse engineering in some jurisdictions.

Removing and/or obfuscating OpenSSL will not really help if the application embeds secrets or try to do "content protection"; the endeavour is hopeless anyway (that's case 1). As for case 3, there is no intellectual property to protect in AES because AES is already public, and is not the vendor's property to begin with. However, obfuscating OpenSSL (or removing it and replacing it with a homemade implementation, or any other ritualistic incantation) can go a long way towards helping the designer sleep at night; if that's what it takes to make him happy...

The underlying idea is that despite what some people strongly believe or claim, obfuscation does not work. Well, it does not break the code, the software still works after obfuscation; but it does not increase technical security against reverse-engineering, and does not improve content protection. The one point which may make obfuscation a rational decision is legal qualification; and that one does not apply to OpenSSL, which is already open-source.


When and why to send an email notification of password reset

At most websites I use, especially for my 401(k), I get an e-mail every time I change my password changes.  Given that it is something that affects my financial future, I appreciate that so I know right away if the password were to change and I didn't initiate that.

In respond to your question, it depends.  For a website that just wants people to log in for some reason (such as a pizza place that doesn't store my credit card info or address), it may not be a big deal to notify people of a password change.  For anything with privacy or security issues, such as medical, financial, IT security, anything to do with minor children, or other such systems, I'd say that notification of all password changes, immediately, would be mandatory.  For code repositories, I'd want to know if someone is logging in as me so I can prevent theft of my company's or my personal intellectual property. For that I'd send a notification of a password reset so the user could ensure that code being uploaded/downloaded by them is being done from the appropriate repository.


How to set up firewall on Mac and/or iOS?

Mac OS X comes with two firewalls installed by default. One visible is System Preferences is the application firewall and won't be of any help in this case.

The other is a packet filtering firewall called pf, however it does not offer a GUI.

Basically you need to block all outgoing connections on your regular network interface except the one to the VPN server and pass all traffic on the VPN interface.

The configuration of the firewall is in the /etc/pf.conf file. You need to add at least the following rules (the following assumes your regular interface is en0 and VPN's tun0).

block out on en0 from any to any
pass out on en0 from any to <vpn_server_IP>
pass out on tun0 from any to any

Remember that the last rule "wins".

After modifying the contain file run to load the rules:

pfctl -e
pfctl -f /etc/pf.conf

To disable the firewall run:

pfctl -d

The rules above are minimal ones for the purpose you specified, you might also need to add a rule to access your local network through the regular interface. Also they block DNS, so you'd need to specify the IP of the VPN server not its DNS name when connecting.


Some password hashing function traditionally encode the salt and the hash output as a single string, so the salt is there, but does not appear in the database as a specific column. Most bcrypt libraries do that. This might be the case for your system.

Also, the salt might be implicit (e.g. computed as the concatenation of the user name and a row ID, or something like that).


Should all the headers reported by securityheaders.io be considered as findings?

Findings are not Vulnerabilities
Should missing security headers be considered a "Finding"? Yes, absolutely. You found a state in the system that is not in accordance to best practice. But what matters is that you put it into proper context. For example, a missing Content Security Policy header is definitely a finding, but not necessarily a vulnerability.
Are those headers required?
"Required by whom?" I would ask back to you. If the security requirements the company itself writes dictate that all web-applications must contain all security headers that are considered best practice, then they are definitely required.
I'm not in the position to comment whether or not there is a legal requirement to have them, although I personally have never heard such a thing.
How should I proceed when I see missing security headers?
I report them as an informational finding. They're a missing security feature, and they should be implemented if it is possible. I would put a bit more emphasis on them if there were related attacks (e.g. XSS and a missing CSP), and would explain how the presence of this header would have made the attack more difficult or even prevented it, but it should still be treated as a low-severity finding.


Is HTTP Digest + MD5 still an alternative to consume my own api?

Collision attacks are not relevant to the use of a hash function in the "Digest" authentication; that one uses preimage resistance for which MD5 is still quite sturdy.

Note that as long as you use SSL/TLS (i.e. HTTPS) then you can use Basic authentication: the SSL layer ensures that the password does not travel "as cleartext", and also that it is sent only to the rightful server. Also note that without SSL/TLS, you have other problems beyond authentication, e.g. hostile hijack of the connection after the authentication phase. For reasonable security, you really need SSL, and once you have SSL, then Basic authentication is fine.

In fact, Digest authentication introduces extra issues, not because of MD5, but because it forces the server to have a copy of the password; so the server must store the passwords "as is", and any local read-only breach on the server becomes critical. With Basic authentication, the server only needs to store hashed passwords (with a good password hashing function), and that's much better.

So don't use Digest, use Basic. But it is not a matter of "MD5 weakness"; Digest with SHA-256 would be no better.

As for OAuth, its main use is to delegate authentication, which may or may not be a good idea in your case, but is another matter altogether.


Should I mount my mac Truecrypt Volume elsewhere?

If I understand your question correctly....

You shouldn't mount an encrypted volume, something you presumably value a great deal, into a folder where a third party application uploads the your unencrypted files to "the cloud" At that point your files are only as safe as Dropbox or Sugarsync.

So, you CAN mount it there... but only if you want your stuff to automagically start uploading.


Is there anywhere we can scan projects (PHP, JAVA...) for vulnerabilities, like VirusTotal.com does (All-in-one)?

To my knowledge, there is not a comprehensive, all in one solution that can effectively scan for different types of vulnerabilities on different types of projects. This is partially due to the fact that the type of data store required for that solution is immense, therefor many products have chosen to tackle a specific issue and excel at that verses being an inch deep across multiple vectors.

At a high level, I like the idea. I think it's probably a great niche for a business, but it would require that an appropriate team be assembled with enough knowledge around all of the fields you would like to support to be beneficial. Half way implemented features would not do this service any good and it would be dropped in favor of the specific tools that meet the needs of current processes.

There are some challenges I think you'll need to think about:

The number of programming languages that need to be evaluated
The number of potential CI/CD pipeline configurations
The variation of OS systems and patching levels
The limitations of cloud based security systems (AWS wont let you scan)
Desktop application scanning
Web Application Scanning
Mobile Application Scanning
Potential integration with multiple code repositories

Again, it's not a bad idea in theory. But taking it to production is a feat that I'm not sure anyone is really ready for at this point.


Only one entry in No-SQL database needs encrypting

It depends on how you store, manage, and use that secret key. (You meant "secret" key, not "private" key, I assume. If it's locked in a secure file, that's about all you can do short of having a hardware security module.

But it's still close to security through obscurity. If an attacker has all the time in the world to explore your systems, is a trusted insider, or if it's a commercial product, he will find out how to become an admin, access your key and decrypt it. But if it's a snatch and grab crime of opportunity, you might get lucky because he may not bother to grab "encrypted" data, or know where to find the key. So in that sense it reduces a small bit of risk. These days, I'd take that over storing plaintext.

Just know that it's not perfect security, and it shouldn't be your only defense.


Choosing a cipher and MAC for an SSH connection

In the first messages between client and server, both send their list of supported algorithms, in order of preference. Then the algorithm that will be used is the first one on the client list that also appears somewhere in the server list. This is specified in RFC 4253, section 7.1:

  encryption_algorithms
     A name-list of acceptable symmetric encryption algorithms (also
     known as ciphers) in order of preference.  The chosen
     encryption algorithm to each direction MUST be the first
     algorithm on the client's name-list that is also on the
     server's name-list.  If there is no such algorithm, both sides
     MUST disconnect.

  (...)

  mac_algorithms
     A name-list of acceptable MAC algorithms in order of
     preference.  The chosen MAC algorithm MUST be the first
     algorithm on the client's name-list that is also on the
     server's name-list.  If there is no such algorithm, both sides
     MUST disconnect.

In other words, the protocol is such that the client's preferences take precedence over the server's preferences.

The normal SSH model (for both SSH v1 and v2) is that the client remembers the server's public key. When the client first connects to a given server, the client displays the hash of the apparent server public key to the user; the user is then supposed to check that hash with regards to some reference value provided by a trusted sysadmin (e.g. the user might phone the server's sysadmin to get the expected hash value, and compare). The client software will then remember that public key (e.g. in the .ssh/known_hosts file), and further connections will check the server key by simply comparing it with the remembered value.

This model is vulnerable to MitM only if the attacker acts during the very first connection, and if the human user is lazy and does not check the hash value as he should (in practice, 99% of human users are lazy).

This model has not changed between SSH v1 and v2. However, modern SSH v2 implementations also optionally (but not commonly) dabble in certificates, allowing the use of a CA-based model instead of the traditional model explained above. I have yet to see that kind of certificates-for-SSH really used in practice, though.


Is OpenSSL CCS Injection (CVE-2014-0224) critical?

CCS Injection requires an active attacker, but does allow an active attacker to downgrade the connection to a predictable key, so the attacker can then read all traffic being passed.  It requires both endpoints be vulnerable, so not nearly as many users should be affected as were for heartbleed.  That being said, an active attacker can recover 100% of the traffic from sessions that they are able to MITM.

So fewer users at risk, harder to execute the attack, but when executed, arguably much worse (100% session recovery).  I would upgrade immediately.


Is it a security vulnerability if the addresses of university students are exposed?

I am sorry for my lack of knowledge in this matter.

You shouldn't be.

  Is it universally approved practice for universities to expose the name and addresses of students?

As pointed out in comments, it depends on your local laws and regulations. You should certainly check it once. But the way you describe the application(changing the URL to get the details, including the result), it sounds like a bug, which should certainly be reported.

  Is it universally approved practice for universities that strong security related to name and address is not important?

No, be it a university or a big MNC or a small enterprise, or your own personal account, security is ALWAYS important.

  Is it a severe attack and do I have to report it to them? Or it can be simply ignored?

Yes, you have to report it to the university, as soon as possible. It should not be ignored.

EDIT: As pointed out in comments, there are some universities which do allow students' addresses to be made public.


Java command execution without Runtime.exec

Java as a platform, and the developers attracted to this platform, are both naive. Shells are extremely common in the Java ecosystem, and especially web applications. The most common ways that I shell Java Apps are as follows(not ordered):

Deserialization  (Too easy, jboss you are too kind :)
Insecure File IO (NULL byte injection still works :)
archive directory traversal (why is this default?)
template injection (Everywhere, every language)
Using the admin panel to upload a war (Default creds ftw)
Creative XXE chains (Why is XXE still the default? What year is it??)


How to find PHP filename and ID of the URL?

No, there is no way for you to find this.
The reason for this is that rewrite rules are not visible to the client, as they are performed server-side. You further cannot be sure whether or not it is a simple rewrite, or if the whole HTTP request is handed over to a complex web application, which parses the route to determine which class and method sends the response.