Is a VirtualBox guest isolated from the host? I have a Linux machine running Kubuntu 20.10.
I have installed VirtualBox 6.1. I then created a virtual machine on which I have installed Windows 10.
Suppose an hacker enters in my Windows 10 guest.
Will he be able to see the files of my Kubuntu host (I mean, the files not in the shared folders, of course)?
How does the answer changes if on the guest machine I have the VirtualBox add-ons installed?

While there is isolation between the VM and the host this isolation is not perfect. Compared to using two different physical machines it is sufficient if the attacker can use a security issue in the hypervisor to escape out of the VM.
Such security issues are often in parts of the hypervisor where interaction between the VM host and the VM is done, i.e. emulated drivers etc. Guest additions also have such code, which means that they additionally increase the attack surface. Such vulnerabilities were found in the past, see for example 10 new VM escape vulnerabilities discovered in VirtualBox.


Securing ECC Private keys What would be the equivalent to securing ECC private key similar to how RSA private keys are password protected through the PKCS#12 format?

Another question I have is: how do I add ECC keys to a keystore such as JKS or BKS, or is there a mechanism to maintain ECC private securely on the server and password protected copies that can be used for exchange of keys with party I am working.

Basically I want to decrypt using ECIES and I plan to use Flexiprovider in a  webservice hosted on an Ubuntu 14.04 server, running Apache Tomcat 8.0.15. The webservice would basically decrypt and do additional processing..

So am I storing and loading keys in my webservice from the keystore? What is the recommended approach?

Thanks and really appreciate detailed response since I am just getting started on encryption / decryption using ECIES..

PKCS#12 uses a generic and standard format for privatekey entries (PKCS#8) which supports ECC as well as RSA and other algorithms, so for software that supports ECC in the first place, the equivalent of PKCS#12 is PKCS#12. PKCS#12 is a good solution for password-protected transfer as well as storage. Formally PKCS#12 can be used with no password, but neither Java JCE nor any other software I know of supports it. However nothing prevents you from using a weak password; if you want actual security, choose the password(s) well.

JKS also uses a generic format for privatekey, but (IME) the password "protection" can be provider dependent. If your JVM/JRE uses any ECC provider you can create a privatekey (with at least dummy cert, and preferably real cert chain) in JKS, or import a privatekey (with cert chain) from PKCS#12 to JKS, with standard keytool. However, if your application uses a different ECC provider, namely flexiprovider, it may fail to use that key. If so or to be safe, create or import with keytool specifying the particular provider here flexiprovider.

Note you can never have a privatekey alone in a JKS, it must have some kind of cert chain, even it's a dummy selfsigned cert that nobody trusts. Of course for an asymmetric key to be actually useful for securing data it needs adequate integrity assurance, like a PKI certificate or PGP-style web-of-trust. FWIW, JKS also uses a generic format for certificates, namely X.509.

AFAIK BKS is custom to bouncycastle and only supported by the bouncycastle provider. I expect you probably can't use BKS with flexiprovider for any privatekey (and maybe not even cert), although it wouldn't hurt to test. However the bouncycastle provider is documented to support ECIES, so you should be able to use BC for ECIES with the privatekey in BKS.


Pitfalls of using OAuth for mobile Applications OAuth is a popular authorization solution for web applications and mobile applications.

What the pitfalls of using OAuth are in those two scenarios (as a web application providing OAuth access to my users information to other websites, and also providing access to mobile (eg, Android, iOS) applications.

Well the first consideration is that SSL/TLS is absolutely necessary to implement correctly.

One must also consider 2-legged or 3-legged authn mechanisms. While most are going to recommend the more complex (and safe) 3-legged approach, it is possible that 2-legged would have advantages when done right for certain apps.

There have been some timing attack discoveries on OAuth done by rootlabs. There are also risks from XSS/CSRF and ClickJacking (and other attacks against the authn), just like in any web application.

ArsTechnica ran two articles on the OAuth security architecture, one linked from Bruce Schneier.


Can a spam email full of junk characters be dangerous? Recently, I've been receiving emails from JP MORGAN CHASE that are blatant phishing attempts. Out of curiosity I have opened them a few times, and they're just completely full of absolute junk characters; lots of symbols, essentially akin to WingDings from Microsoft Word. On my desktop computer, Mozilla's Thunderbird seemed to open the email without any issue, but the Outlook mobile app on my S20 seemed to hang significantly on this email, and thankfully I was able to close the app. There don't seem to be any ill effects from opening it, either on my Desktop or my phone, but my question is:
Can a spam email full of junk symbols and characters be problematic for certain devices? Is it an attempt to phish or to brick a device?

It's probably an encoding or rendering error by the sending software and/or (less likely) your mail delivery infrastructure or mail client. It would be helpful to see the Content-Type and Content-Encoding headers and MIME headers to see how the sending software specified your client should read the message.
It's always possible that it's just nonsense spam, sent to distract spam filters and harm their accuracy so that spam with real payloads can be delivered later (see also Hash busters and Bayesian poisoning), but it's more likely that the attacker messed up the encoding.
Remember that lots of spam comes from botnets, meaning the message content needs to sneak through anti-virus, then decrypt/decompress, then spew out into the world. There are lots of places that could have gone wrong.
The likelihood that this content could itself be harmful to your computer is close to zero. There could be some odd 0-day that it takes advantage of, but not that I've heard of (that would be huge).


Why only Google warn us about attackers? There are so many search engines like ask.com, yahoo.com and many more, but only Google warn us about attackers. Why so?

There are so many search engines like ask.com, yahoo.com and many more, but only Google warn us about attackers. Why so?

Just because it says Google it does not mean it is related to the search engine.

Google Safe Browsing is a service run by Google, but it is not directly related to their search engine, same as Google Cloud, Youtube etc. are not directly related to the search engine either. Use of Google Safe Browsing is integrated into at least Chrome and Firefox.

The is a similar service for Microsoft browsers (Microsoft SmartScreen), which is run by Microsoft and which is also not directly related to their search engine. Several security companies have similar services for their firewalls (i.e. blacklisting malicious sites) even though they don't have a search engine at all.


Open Source Security Dashboard? I'm looking for an open source security dashboard that gives a basic overview of security warnings. Google has pointed me in a few directions but nothing promising. I need something to deal w/ selinux alerts, mod_security violations and hopefully have an api that can send/create new alerts to display (i think i might be asking too much, sadly). A few have suggested custom graphs in kibana but would be nice to hear other peoples thoughts.

Thanks

Have you considered using Splunk?

Very easy to set up, with apps available for *nix platforms and mod_security ready.

Splunk isn't open source, but free to use for up to 500mb of data per day - you can send data via regular syslog, or using their universal forwarder. Their dashboards and charting capabilities are fantastic and easy to use.

You can set up alerts to send emails, trigger actions, run scripts, etc.


Client side signing of a file(.exe,.dll,.jar..) using CA issued certificate and signtool In a current project we have purchased certificate from a trusted CA and have installed in a host, sign tool is also installed in the same host.

All the files which we develop(jar,dll,apk,exe etc..,) needs to be signed, so we use the certificate and sign tool hosted in a central server.

When ever a developer wants to get his file signed , he will upload the file to the remote host where the Certificate and sign tool resides and signed file is downloaded.

Now since the file size is increasing day by day we will not be able to upload the entire file to a remote server to get is signed, is there a way to sign the file at client side and send only the hash value back to server for reference???

In theory, what you're asking for is possible: code signing basically is just signing a file hash so there is no reason why you have to do that at the same place the hash is calculated.

In practice, though, I'm not aware of any way you can do that without writing your own code signing code - something that you should really not consider. It would be a delicate problem because you'd have to secure the system very tightly.

That being said, I cannot really imagine a setup where uploading your code to a signing server would be impossible or even very difficult. I suggest you concentrate on that aspect of your problem instead.

Edit: In view of Jonathan's answer, I think I have to add a word of warning about trying to change existing code to implement such system.

First, it can be done. In fact, after checking my own (read: the code I use, which is professionally maintained, and not any code I wrote myself) code-signing libraries, it wouldn't be too hard (at least not at the code-signing level).

That out of the way, you need to consider the consequences: first, the tools and library you use would then immediately stop being supported by your provider (whoever they are): if there is any bug in it that is fixed at a later date, you'll have to implement the patch yourself (assuming you can). This is incredibly uncomfortable from an operational point of view.

Second, writing crypto code is HARD and writing a safe crypto-based product is even harder. While it can be quite interesting to do so "for the fun", a professional, production-ready system needs much more resources than a single person: it's really a team effort that requires formalized testing.

So, given that your issue seems to be that you have a single instance of a problem (your code base is so big that you're having issue uploading it to the server), I think it's a problem that needs to be solved at one location, not get a universal solution.

Now, if you want to produce a new product that solves the issue of code signing for teams (and there might be a market for that), that's a different issue altogether (but not one for this place).


Can someone get my WPA2 password with honeypots? Yesterday I went to my cousin's home and I saw that I'm not connected to his wireless (for internet access). Then I have looked up the list of wireless points. I have found his name and clicked it connect, I have entered his password (which I know) and it didn't connect. Then I've asked him whether he changed the password and he told me that he didn't and it is because just the wireless device is closed. So I thought, could it possible that the password I have entered was "taken" by the guy next door?

I don't know whether the plain password is send to the device. And I think you call it Access Point.

Yes and no. They may not have your password in plaintext, but they have enough to potentially guess it and verify that guess (i.e. offline brute forcing).

WPA2 authentication is performed through a four-way handshake. Instead of just sending your password in plaintext to any access point you connect to, this handshake ensures that unless both parties already know the password, the password (or any attempt at it) is not revealed. However, enough of that four-way handshake can be recovered to make offline password cracking possible.

Please understand you risk this every day. The network manager on your computer/device is probably configured to automatically 1) search for familiar access points by sending out beacons (thus advertising what is familiar to it and essentially how to mimic it) and then 2) automatically connecting to any familiar access points that responds. Even if you are currently connected to a wireless network, an attacker could disconnect you via a deauthentication attack and then lure your device into connecting to their honeypot.

What can you do to protect yourself?

Chose a password that is tough to crack.
On your device, disable automatic connections to so called "familiar devices".
Refuse to connect to wireless networks with weak passwords.

Friends don't let friends chose weak passwords.

Stay away from any WEP or unencrypted networks. Seriously.

If you are interested in 802.11 (aka WiFi) security, check out Vivek's "WLAN-Security-Megaprimer" on SecurityTube. There is a lot of FUD and misinformed articles on wireless security, but the material of Vivek Ramachandran and (when you're ready to try attacking yourself) the documentation on the aircrack-ng wiki are solid. I can not recommend Vivek's material enough. Also, this article on the security of WEP, WPA, and WPA2 seems promising.

You are doing a great job thinking about security and asking the right questions. The next step is to attack yourself. Remember to stay paranoid.


How to track anonomous SMS on your smartphone I sometimes receive sms from unknown numbers asking me to send money on another unknown number.

Is there a way to track the source of such numbers through logs or other technologies or solutions?

Contact your mobile network

The best solution is to contact your mobile network. They can track the sender and help you.

  I sometimes receive sms from unknown numbers asking me to send money
  on another unknown number.

This sounds like a scam and your mobile network operator or carrier can block the senders for you if requested.


userWorkstations attribute in AD preventing users from logging into WebApp For some of our users in AD, we have set userWorkstations attribute to restrict access to other machines.
But this is preventing those users from logging into WebApplications (around 50+) protected by Access Manager(in our case OpenAM).

One way to resolve this issue is to Add the AD-DC name in the list of allowed work stations for that user.
But I am not sure about the security implications as a result of this change.

Is there a better way to approach this ?

If you add a domain controller in the list of Logon Workstations for a user account, you are saying that the specific account is not restricted, from the account level, from logging onto that DC. However, this does not bypass other security such as Allow logon locally or Allow log on through Remote Desktop Services. So, for example, if user jsmith's account has dc1 in Logon Workstations, this doesn't automatically mean that jsmith really can log onto dc1. It just means that the settings on the account does not prevent it.

One drawback of this scenario is that it is confusing: If an administrator looks at jsmith's list of Logon Workstations and sees a domain controller, he or she may wonder why this attribute is set on this account (particularly if the account is not noticeable as some kind of administrative account). Good system documentation can mitigate this confusion.


IPSec, hubs, crypto maps I thought hubs were layer 1 devices, and so would have no active role in IPSec. I am reading to understand crypto maps,

  Dynamic crypto map policies are used in site-to-site VPNs when an unknown remote peer tries to initiate an IPsec security association with the local hub. The hub cannot be the initiator of the security association negotiation. Dynamic crypto policies allow remote peers to exchange IPsec traffic with a local hub even if the hub does not know the remote peer's identity.

and apparently a hub may know the identity of a peer. If a hub is layer 1 only, how is this possible?

I think it's referring to "hub" as the center of a hub-and-spoke VPN architecture, as shown in this diagram.

Later on in the document you linked to, it says:

  Dynamic—Dynamic crypto maps can only be used in a hub-and-spoke VPN
  topology. Dynamic crypto map policies allow remote peers to exchange
  IPsec traffic with a local hub, even if the hub does not know the
  remote peer's identity.


VyprVPN (from GlodenFrog.com) weirdly keeps sending unauthorized suspecious data even after uninstall Update:

Check the VyprVPN's app developer answer below, seems this is okay and an uninstaller is added to new versions to prevent such issues.

Original:

I was working with VyprVpn a few months ago, never worked with them again,

Today I installed LittleSnitch (An OS X Firewall and Network Monitor),

Noticing The Issue

  I noticed weird outgoing data to domains like: goldenfrog.com,
  dl.succentric.com , dl.bondwidth.org , dl.4titude.net ,
  dl.trajectore.com etc
  Every few seconds...

  There is no mention of this kind of activity on their website, they didn't come clear, also the support staff seems to be unaware

Then i get Whois for these domains, all registered at Tucows and have DNS *.DATAFOUNDRY.COM

But Goldenfrog is registered with valid information and the others are all protected whois for privacy...

Unistalling

Then i uninstalled VyprVPN Application with AppCleaner which looks for every related file and folder and deletes them too.

Even after uninstall

Outgoing traffic to all these domains was still happening every few seconds,

  Please note there was no process with the name of Vypr... or
  Goldenfrog... in the Activity Monitor

I searched a lot and also used sudo launchctl unload /Library/PrivilegedHelperTools/vyprvpnservice to unload their helper, put the loader in trash, restarted and emptied the trash

And finally it wasn't happening anymore

Questions

Is this kind of activity normal in VPN providers? they are legally registered company, claim that respect privacy...
Are they allowed to send such data without letting us know about it when ordering, or without doing it with a process named under themself?
Overall would you use their service after this? no other service is doing such thing

I'm asking because i want to be sure and alert my friends to stop using Vypr because its dangerous

Hi I'm the developer who wrote VyprVPN for Mac. It looks like you've still got one of our software components installed. Macintosh applications that needs to alter your system, including VyprVPN, uses something called a "privileged helper tool” aka a system daemon.  We install a helper tool with the user's permission, using the appropriate Apple API for this purpose, that runs in the background and does things like setup the VPN, manage kill switch rules, etc. This is the component that is performing the operations you are seeing.

In recent versions of our software, we include an Uninstaller on the .dmg. Mount the .dmg and scroll down and you'll find an app called "Uninstall VyprVPN.app". Run that. It will remove the privileged helper tool.


Algorithm to implement symmetric encryption in VB.Net for Windows and in Swift for iOS I need to implement symmetric encryption to enable secure communication between one program running on a Windows machine (to be written in VB.Net) and an app running on an iOS device (to be written in Swift).  I'd like to use a reasonably modern algorithm which is supported in both programming languages "out of the box" without having to import more code than necessary.

The use case is, information (mostly, text files) will be encrypted by one program (say, running on Windows) and uploaded to a server, where it will be stored, then later downloaded and then decrypted by the other program (running on iOS).  The server doesn't need access to the content of the file, and having the information "encrypted at rest" on the server is the main goal, although having it encrypted during transit to/from the server is also beneficial.  The Windows and the iOS devices themselves aren't considered to be targeted in this case.

What algorithm(s) are good choices as being modern, secure, and available in both Swift and Dot Net so that what's encrypted by one can be decrypted by the other?

AES-GCM (Advanced Encryption Standard in Galois/Counter Mode) is the go-to standard for secure symmetric encryption these days, and is very widely supported (some libraries might still call AES "Rijndael"; just stick to 128 bit blocks and 128, 192, or 256-bit keys and it should be compatible). You can use AES with other modes, such as CBC, but this opens you to additional risks such as padding oracle attacks and additionally requires using another primitive (such as a secure hash function) to provide integrity for the encrypted data (using a construction such as an HMAC). GCM (if used correctly) authenticates the data for you, which most ciphers and "modes of operation" do not. However, GCM is somewhat tricky to use safely; there are alternatives such as [X]ChaCha20-Poly1305 (the ChaCha20 stream cipher - or its XChaCha20 variant - with an authenticated encryption) that are preferred in some implementations.

HOWEVER, having said that, you should consider using a library that already implements the crypto for you and was written, reviewed, and tested by experts. Crypto newbies should not attempt to use cryptographic primitives (such as AES) directly unless they have no other choice (it's just way, way too easy to screw something up; even experienced crypto developers miss things and it sounds like you don't even know what to look out for). One such library is "libsodium", although even it might be a bit much for a raw beginner. It is written in C but does have lots of bindings for other languages (including .NET and Swift). It includes functions to do everything you need.

Of course, once you've got your crypto library (third-party or hand-rolled atop the primitives), you still have the question of where and how to store/transmit the key. It doesn't do any good to encrypt something if the other side can't decrypt it, and it also doesn't do any good to encrypt something if everybody can decrypt it (which is what you'll get if you try doing something like hard-coding the key in the app). Using a password (via a "key derivation function") is one option. Another is to transmit the key (through a secure channel, such as HTTPS) to the server, but then the encryption isn't truly end-to-end; the server has everything it needs to decrypt the data, and if the server is ever compromised then the attacker will be able to decrypt the users' data too.

End-to-end encryption is hard to do right. Even a relatively simple cryptosystem is a massive pile of things that are easy forget or mess up, and a simple mistake can mean it all falls apart. As a general rule, if any of the algorithms or considerations I mentioned in this post are things you haven't heard of before, you should probably do some more reading before you try to write this code. I've seen lots of developers - even at big, highly-exclusive software companies with huge amounts of institutional knowledge - try to write their own cryptosystem and screw it up, often in some way that completely breaks its security.


Is uninitialized memory considered sensitive? Consider a program that can allocate and read uninitialized memory regions, e.g. for performance reasons.
Should said program assume that those regions may contain sensitive information, or is it the previous owner of those regions responsible for writing 0s before deallocating them?
I am almost certain that it is the latter, as the former would require all uninitialized regions to be assumed to be "sensitive", but I could not find any authoritative source on this.

From an application development standpoint, you should never presume that memory will be zeroed unless the allocator API you are using explicitly guarantees it. Making that assumption without a guarantee may lead to memory corruption and undefined behaviour. This may have security consequences, but more importantly it's likely to cause subtle and hard-to-reproduce bugs.
Your memory allocation API should always clearly define the initialisation status of the memory it is allocating for you. For example, malloc does not guarantee that memory will be zeroed, but calloc does. You can design your code with this in mind.
It is also important to distinguish between the behaviour of a heap allocator that is implemented as part of your application and a the operating system's memory allocator.
On any mainstream operating system, the memory manager will ensure that pages are scrubbed (i.e. cleared of previous data) when allocating them across a security boundary. This means that if a memory page was allocated to one process, filled with sensitive information, then freed and re-allocated to a different process, the memory manager must scrub the page. If the page is freed and re-allocated to the same process, it does not have to scrub the page, because the page is not transitioning across a security boundary.
A scrubbed page does not have to contain zeroes. It may contain some other constant value instead. Some memory manager systems scrub pages to some hexspeak value so that it is easy to tell when memory has not been explicitly zeroed. Refer to your OS's API documentation for details.
The same restriction exists for VMs. If the VM host is remapping a page into a guest VM's memory space, it must scrub that page first. Not only that, but the CPU cache must also be flushed when performing a context switch back into the execution context of the VM. This reduces the possibility for cache-sniffing attacks that leak host memory into a VM.
A heap allocator library (e.g. stdlib malloc, jemalloc, tcmalloc, ptmalloc) implements heap management inside an application, abstracting away the specifics of the platform's memory management APIs. Since the memory pages being allocated by these allocators are inherently kept within the process boundary, there is no situation in which a dirty memory page can cross a security boundary into another process and be re-allocated there without scrubbing.
In some threat models you may be concerned about sensitive data remaining in memory beyond the lifetime of the allocation or the process. While another process cannot directly access that sensitive data, since the OS memory manager will scrub it before reallocation across a security boundary, there are threats such as forensic memory acquisition or DMA attacks that bypass the allocation scrubbing policy by accessing physical memory pages directly. In such cases you would want to scrub the pages manually before freeing them.
One critically important detail here is that simply looping over the memory and setting it to zero (e.g. with memset) prior to freeing the memory is not guaranteed to be effective. The compiler may detect that the memory is not accessed after being written and eliminate the zeroing operation as an optimisation.
Available solutions for this scrub elimination problem are specific to the language, toolchain, and platform:

-fno-builtin-memset in GCC to turn off memset elimination
memset_s as a non-standard approach in C11
SecureZeroMemory on Windows (although that may be deprecated?)
Casting the target memory as volatile in your zeroing loop in C/C++ - this tells the compiler to assume that something outside its view might be modifying the memory, preventing the elimination optimisation.
SecureString in .NET applications (memory remanence is a complicated topic here due to string immutability and GC, and you have to be very careful with your usage even with SecureString)
GuardedString in Java applications (similar practical problems to .NET)
secstr or similar in Rust
sodium_memzero from libsodium, ideally alongside their other secure memory APIs.


How to build a secure socks tunnel? I was using a socks proxy to access websites blocked by my ISP, now it don't work any more in an strange way. Using the proxy is same as not using it! (i.e. I can access open sites but filtered sites are filtered even through proxy.)

I want to know what can case this?

And is there any way to make a secure tunnel other than ssh?

You can establish a secure tunnel using SSH, OpenVPN, or any other VPN service.  Search this site for information on setting up a VPN.

Is it possible your ISP is blocking DNS access to those sites?  If so, there are two steps you can consider:

Route DNS through the SOCKS proxy.  You may need to configure your browser to do this.  On Firefox, set the network.proxy.socks_remote_dns configuration setting -- but see How to secure Firefox traffic (+DNS) through SOCKS proxy under Ubuntu 10.04? for some information that may be relevant.
Manually configure your computer to use a DNS server of your choice, not the ISP's DNS server.  You could use Google's DNS server (IP address 8.8.8.8) or OpenDNS.  Note that this may work (e.g., if the ISP is filtering its DNS responses in its own DNS server), but it may also not work (e.g., if the ISP is using dynamic packet inspection to inspect and modify all DNS traffic regardless of destination).

If simple solutions don't immediately work, I'd seriously consider trying a VPN or Tor (either Torbundle or a LiveCD).


Difference between Certificate Authorities I've been wondering for a long time about is. There are many certificate authorities having different types of certificates. But even certificates of the same security level cost a lot more with one certificate provider than with the other.

I'm aware that there are many types of certificates, but even certificates of the same security level cost a lot more with one certificate authority than with the other.

For instance rapidSSL offers certificates at 50 dollars, but if you want the equivalent from Verisign you pay 10 times that amount.

I'm just wondering what the difference is between all the authorities. Is it just a marketing strategy, because people think: "The more expensive, the more secure?".

Some possible reasons why a CA might be able to charge more than a rival:

They have a better reputation.
They have better customer services.
They are trusted by all the browsers out of the box.
They do better and more expensive due diligence of the companies they issue certificates to.

(This last one is irrelevant in practice, since almost everyone just accepts the CAs that come with their browser without question, but I expect a CA might cite it as a reason they have to charge more!)

I use one of the more expensive vendors myself, as it happens, but I'm quite happy to pay the few dollars extra because the customer service is very good. I screwed up an urgent certificate renewal once, and they answered the phone promptly, figured out where I'd gone wrong straight away, made sure I didn't notice them rolling their eyes at my stupidity, and got a replacement cert to me within 5 minutes. That's worth a few bucks a year more, I reckon.


What approaches exist for ensuring security when deploying software in non-trusted environments? Is it possible to deploy software in such a way that a rogue actor who has physical access to the hardware is unable to glean any information on the code that is running or what is being stored in memory?

I know there are some more “experimental” approaches such as encrypting data at RAM level and storing unencrypted data in the CPU cache (e.g. TRESOR). Are there any other ways of solving this currently? Will something like a fully homomorphic encryption scheme help with this once they become practical speed-wise?

Is it possible to deploy software in such a way that a rogue actor who has physical access to the hardware is unable to glean any information on the code that is running or what is being stored in memory?

No, this is impossible, for the following reasons:

Physical access pretty much always means game over, so this alone would be a strong indication that what you want is not doable.
No matter how much you try to protect your code and the data it produces, in the end the processor has to have access to both the machine code of your program and the data it works with. Even if your code self-decrypts and encrypts every piece of data before it is moved from a CPU register into RAM, the encryption keys must still be stored somewhere (possibly in registers, too, but that only means they're harder to access - not impossible). I can imagine various ways to access this data, such as dumping the whole RAM into a file, running the code in a debugger, suspending the machine and store away the suspended state for inspection after the machine wakes up again, changing the kernel or libc to help spying on your code and so on.

I don't understand what you mean with "will something like a fully homomorphic encryption scheme help with this", but I doubt very much that it will change point 2, whatever it is.

TPMs provide a way to store keys and do encryption and decryption inside the TPM, so the keys aren't exposed, but again, this only makes it more difficult to get at the relevant information, not impossible.


Exactly why is it not possible to "drop-out" of TLS 1.3 proxy inspection? I have been reading a number of articles that state it is not possible for an inspection proxy to simply drop-out/disengage from a TLS 1.3 connection in the same way that is possible in TLS 1.2.
Such articles never seem to explain exactly why that is the case, for example some simply say "its because the certificate is encrypted".
In this IETF paper it gets a bit closer to explaining but I do not really understand what it means or exactly why it is not possible

This technique is not functional with TLS 1.3 since the transcript
hash over the handshake messages is part of the key derivation
procedure.

Can someone please explain this to me?
Thanks

In TLS 1.2, the master secret, which is used for deriving keys, is derived from the pre-master secret and some additional data.  With RSA key exchange, the TLS middlebox can simply act as the client and send the pre-master secret that was derived to the remote server.  With Diffie-Hellman key exchange, the TLS middlebox sends non-prime parameters (which are usually insecure) based on the server's key exchange parameters such that the computation of the pre-master secret is the same.  As Z.T. mentioned, this is described in the Triple Handshake paper.
In TLS 1.3, the keys are derived from the master secret and a hash of the handshake using HKDF.  Because HKDF is a PRF (a pseudo-random function family), it is functionally impossible to generate the same set of keys when the handshake hashes are different (which they must be if the TLS middlebox and the server present different certificates), even if the keying material is the same.
This was done intentionally for two reasons:

This makes it much harder to conduct any sort of attack on TLS, since the entire handshake, as well as the actual key exchange, influence the derived keys.  It's no longer possible to specifically craft keying material to intentionally derive the same set of traffic keys, which has been used in previous attacks.
Many folks involved in TLS do not like middleboxes, since they rightly see them as an intentional attack on the end-to-end security of the protocol, and this makes them more difficult to implement.


How to get around hard coding a PFX password I've got an application that acts as a SSL server. I've got the pfx file and in code, I've had to hard code the password to use in the following way

PKCS12_parse(p12, PFXPassword, &pkey, &cert, &ca)

The more that I read on here, the more that I'm realizing how susceptible my code would be to reverse-engineering and thus extracting the password out of the code itself. How would I go about protecting myself from this?

I expect my code to be eventually (hopefully) be deployed in boxes that I have no control of, so just keeping it to myself doesn't seem like a plausible idea.

If you ask me having to update code when you change certificates is a pretty poor design, but that wasn't your question.

The only way to protect the private key from the server itself is to offload SSL operations to a trusted host. If you're concerned about the private key's safety on the server, you could get a hardware security module (HSM) which securely stores the private key and performs the necessary crypto operations in a secure isolated environment.

Honestly though, if you're not going to use an HSM you may as well store the key in plaintext rather than hardcode a password into your application because that's only the illusion of protection. Without an HSM, one way or another the server has to have the private key to operate and someone with control of the server can just rip it right out of memory if they want.


Session Authentication vs Token Authentication I am trying to get a handle on some terms and mechanisms and find out how they relate to each other or how they overlap. Authenticating a theoretical web application and mobile application is the focus. The focus is on the exact difference between token based authentication and cookie based authentication and if/how they intersect.

HTTP basic/digest and complex systems like oauth/aws auth do not interest me.

I have a few assertions which I would like to put out there and see if they are correct.

Only using authentication tokens, without sessions, is possible in mobile applications. In a browser context, you need cookies to persist the tokens client-side.
You exchange your credentials (usually username/pw) for a token which can be limited in scope and time. But this also means that the token and everything relating to it must be persisted and handled by the server as well.
Tokens can be revoked server-side. Cookies do not have that option and will/should expire.
Using only cookies means that sessionId is related to the user account and not limited in any way.

I am hoping I am not too far off the mark and am thankful for any help!

In Session-based Authentication the Server does all the heavy lifting server-side. Broadly speaking a client authenticates with its credentials and receives a session_id (which can be stored in a cookie) and attaches this to every subsequent outgoing request. So this could be considered a "token" as it is the equivalent of a set of credentials. There is however nothing fancy about this session_id string. It is just an identifier and the server does everything else. It is stateful. It associates the identifier with a user account (e.g. in memory or in a database). It can restrict or limit this session to certain operations or a certain time period and can invalidate it if there are security concerns. More importantly it can do and change all of this on the fly. Furthermore it can log the user's every move on the website(s). Possible disadvantages are bad scale-ability (especially over more than one server farm) and extensive memory usage.
In Token-based Authentication no session is persisted server-side (stateless). The initial steps are the same. Credentials are exchanged against a token which is then attached to every subsequent request (it can also be stored in a cookie). However for the purpose of decreasing memory usage, easy scale-ability and total flexibility (tokens can be exchanged with another client) a string with all the necessary information is issued (the token) which is checked after each request made by the client to the server. There are a number of ways to use/create tokens:

Using a hash mechanism e.g. HMAC-SHA1

token = user_id|expiry_date|HMAC(user_id|expiry_date, k)

where user_id and expiry_date are sent in plaintext with the resulting hash attached (k is only know to the server).
Encrypting the token symmetrically e.g. with AES

token = AES(user_id|expiry_date, x)

where x represents the en-/decryption key.
Encrypting it asymmetrically e.g. with RSA

token = RSA(user_id|expiry_date, private key)

Production systems are usually more complex than those two archetypes. Amazon for example uses both mechanisms on its website. Also hybrids can be used to issue tokens as described in 2 and also associate a user session with it for user tracking or possible revocation and still retain the client flexibility of classic tokens. Also OAuth 2.0 uses short-lived and specific bearer-tokens and longer-lived refresh tokens e.g. to get bearer-tokens.

Sources:

https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
https://stackoverflow.com/questions/1283594/securing-cookie-based-authentication
https://web.archive.org/web/20170913233103/https://auth0.com/blog/angularjs-authentication-with-cookies-vs-token/
Demystifying Web Authentication (Stateless Session Cookies)
https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication


How much damage can a malicious package do with just "npm install "? I had a typo and npm installed something that is similar in name to something very popular -- I was concerned about typosquatting.  It's quite plausibly legitimate and just a coincidence.  I looked at the corresponding package and didn't see anything wrong, though of course bad things can be hidden.
I use nvm.
I npm installed it and then immediately noticed and rm'd node_modules.
How much damage can be done by just installing, without subsequently "using" it for anything?
I know very little about npm -- does npm allow the installation code to do whatever it wants on a system?

Conceptually, installing a package permits running setup scripts which in turn could be leveraged to execute arbitrary code on the system under the privileges of the executing user (hope it wasn't root... though if it was the worst consequence is full compromise of the system). The package may also pull in other packages as dependencies which in turn bring the same level of risk.
If you're concerned, create yourself a sample VM and unpack the package to see what it does. It's uncommon (but has happened!) that signed packages from trusted sources contain malicious code, but you can't be sure until you check.


Why local variable is not overwritten due to buffer overflow? Here is the my C++ program in which buffer overflow happened, still the local variable is not corrupted:

#include <iostream>
#include <cstring>

using namespace std;

int main() {
    // your code goes here
    int i = 20;
    char var[4];

    strcpy(var, "biiiiiiiyee");
    cout<<" var is : "<< var << endl;
    cout<<" i : " << i << endl;
    return 0;
}

The output of program is :

 var is : biiiiiiiyee
 i : 20

The assumption is that overwriting past the end of the var buffer should corrupt the i variable.

In the above program I'm overwriting the buffer, still the local variable did not corrected. Why?

Alignment.  The compiler is allowed to place local variables on the stack in a way that the alignment to the CPU words is better.  In other words, there is nothing that forces the compiler to place local variables one after another on the stack.  Actually placing local variables one after another would be saving a couple of bytes in program size for a considerably big penalty in processing time.

Allow me to use plain C instead of C++ to explain 'cause it is much easier to drop it into GDB.  Program converted to plain C, let's call is pp.c:

#include <stdio.h>
#include <string.h>

int main() {
    int i = 20;
    char var[4];

    strcpy(var, "12345678901");
    printf(" var is : %s\n", var);
    printf(" i : %d\n", i);
    return 0;
}

Note that the string I used is of the same length:

"12345678901"
"biiiiiiiyee"

Let's compile it without optimizations, just in case:

gcc -O0 -g -o pp pp.c

And now let's look at the program running:

$ gdb -q pp
Reading symbols from pp...done.
(gdb) list
1   #include <stdio.h>
2   #include <string.h>
3
4   int main() {
5       int i = 20;
6       char var[4];
7
8       strcpy(var, "12345678901");
9       printf(" var is : %s\n", var);
10      printf(" i : %d\n", i);
(gdb) break 8
Breakpoint 1 at 0x4004fa: file pp.c, line 8.
(gdb) break 9
Breakpoint 2 at 0x400510: file pp.c, line 9.
(gdb) run
Starting program: /home/grochmal/tmp/pp

Breakpoint 1, main () at pp.c:8
8       strcpy(var, "12345678901");

OK we are just before the overflow happens, let's see where the stack is and where the variables on the stack are:

(gdb) p $rsp
$1 = (void *) 0x7fffffffe860
(gdb) x/16x 0x7fffffffe860
0x7fffffffe860: 0xffffe950  0x00007fff  0x00000000  0x00000014
0x7fffffffe870: 0x00400550  0x00000000  0xf7a5c291  0x00007fff
0x7fffffffe880: 0xf7dd0798  0x00007fff  0xffffe958  0x00007fff
0x7fffffffe890: 0xf7b9cc48  0x00000001  0x004004f6  0x00000000
(gdb) p &var
$2 = (char (*)[4]) 0x7fffffffe860

Very good, var is really at the top of the stack (0x7fffffffe860) but i is not 4 bytes later.  i is at 0x7fffffffe86c, 12 bytes later (i is 20, i.e. 0x00000014).  Let's see what happens next:

(gdb) cont
Continuing.

Breakpoint 2, main () at pp.c:9
9       printf(" var is : %s\n", var);
(gdb) x/16x 0x7fffffffe860
0x7fffffffe860: 0x34333231  0x38373635  0x00313039  0x00000014
0x7fffffffe870: 0x00400550  0x00000000  0xf7a5c291  0x00007fff
0x7fffffffe880: 0xf7dd0798  0x00007fff  0xffffe958  0x00007fff
0x7fffffffe890: 0xf7b9cc48  0x00000001  0x004004f6  0x00000000

The buffer does overflow!  But not far enough, we need 1 extra byte (remember that that 0x00 is the null terminator) to reach the place in memory where i is located.  If we change our strcpy to:

strcpy(var, "AAAAAAAAAAAA\x39\05\x00");

You get to overwrite i:

$ gcc -O0 -g -o pp pp.c
$ ./pp
 var is : AAAAAAAAAAAA9
 i : 1337

It is not easy to guess alignment, it depends on CPU and compiler.  Most (white/gray/black) hats do it by trial and error, or by compiling the program in the same environment it is run and then looking at it in a debugger (as we did above).


X windows security: VNC and X server vs xpra I have a CentOS server that currently has no X server on it.  It will be used for doing statistical crunching and providing other services (probably via a web interface).  The main security for the box is provided by VPN.

Some of the users will need software that can't function without graphics.  I'd rather not make even a minimal install of an Xserver and window manager, but if I do so I was planning installing X, a lightweight desktop or even just a window manager, and VNC.  Users would connect to VNC sessions via ssh tunneling.  One big advantage of this arrangement is that if the network connection drops, whatever is running persists instead of dying.

For persistence, people in operations suggested I look into using xpra instead.  I did a dry run of an install, and it installs an X server, so at least on its face I don't see any advantage to this approach, either in terms of security or simplicity.

Is there any security reason to prefer the xpra approach over VNC+Xserver+ssh tunnelling?

The "normal" way to use remote X11 is to have the X11 server run not on your server, but on the machine which is physically in front of the user. Then use ssh to do X11 forwarding, so that the application on your server talks to the X11 server that runs on the client machine.

(Yes, the terminology is a bit confusing. "Your server" is the machine you are talking about, and the "X11 server" is the software that manages graphical display, called "server" because it waits for applications -- the "clients" -- to talk to it.)

I understand that you also want to have a sort of "mobility feature" that allows roaming users to disconnect and reconnect from several client machines without closing application, in which case the classic model is not appropriate.

The usual perceived security issues with X11 servers is that they run with high privileges (because they must access the graphic hardware) and they make use of components whose security is often considered as flaky (the drivers for the graphic hardware). Xpra uses Xdummy, which removes both problems: it does not actually talk to real hardware (so no drivers in the loop), and it does not run as root but under the identity of the calling user. In that sense, I would deem Xpra to be "better" for security than running a plain local Xserver exported through VNC.

(Conceptually you could run Xdummy with VNC, but that's basically reinventing Xpra.)

I also expect Xpra to make things much easier, compared to a Xserver+VNC setup, when it comes to:

supporting several users simultaneously;
supporting various screen sizes on the client side.

On the cons side, Xpra is under very active development, which, while ensuring good support, also means that deployed code has not "stood the test of time". Usually, for best security, you want to use software that is well supported but has nonetheless stabilized a bit. This is not a big problem, though.


What is the procedure to implement security zones in a production network without impacting negatively in the communications? In an organization where there exist a network with VLANs where the communication between all VLANs is allowed we are going to install a firewall and define security zones.

The security zones will block all communications by default and we are going to create individual rules for allowing traffic between security zones that need to communicate.

The network is in production with lots of business critical applications and clients communicating all with each other.

What is the best procedure to implement the firewall and the security zones without affecting the production network?

I've got nothing more than common sense to offer.

Tap the network, collect network flows and verify the network flows.
Introduce rules to permit those network flows.

When we did this, we discovered that network flows are a long tail distribution. Work from both ends:

Work with stakeholders to determine business needs, and document those as firewall permit rules.  This requires a lot of soft skill negotiation in tandem with other activities.
Study the high traffic flows, validate that they are aligned with business needs, and permit them explicitly
Study the low frequency network flows and see if they align with business needs; if not, block them
Get access to a blacklist with known bad actors; alarm or block these (this is a good step to use to feed to stakeholders

In each case, when you think you've identified a bad flow, run it as an alarm until you can get stakeholders to agree that it is not aligned with business needs.

Depending on how close you are to your management, I'd measure each of these steps and advertise the results.  Measure the bandwidth through your permit rules and your deny rules and let management know that you've preserved teh value of X MB (and at the current price of bandwidth, that's $)  And you've denied Y MB of traffic (at the current price, that's $.  I'd probably also include that I'm studying ZMB of traffic.  Ultimately your work is blocking attack, preserving network for legitimate uses, and significantly advancing the state of the company's continuity of operations, disaster recover and devolution plans.


Most efficient key algorithm for a TLS server key? Let's assume I want to setup a HTTPS service on a modern-but-no-so-speedy x86 server without any form of hardware cryptographic accelerator.

Which key algorithm should I choose for the server key in order to maximize server performance with respect to TLS connections/second?
Once generated, the public key will be delivered to the CA as part of the signing request.

The server is not critical. A security level equivalent to a symmetric 80-bit key is sufficient: that means (according to NIST) 1024 bits for RSA, 1024/160 bits for DSA, 160 bits for ECDSA, etc.

I can look at performance for raw signing of a popular crypto library to get an idea, but SSL handshake involves more steps than that (key exchange in particular) and I am not sure if the fastest signing algorithm leads to the best overall handshake performance.

With a modern but not-so-speedy x86 processor, and a good enough implementation, cryptography speed will not be the bottleneck. For instance, consider a quite cheap AMD Athlon 2650e processor, a not-so-modern and really-not-so-speedy processor that I have in my home file server; it is clocked at 1.6 GHz and has a single core. It can still do about 2200 RSA private key operations per second (for a 1024-bit RSA key). I seriously doubt that the Linux kernel on which this machine runs can cope with 2200 new TCP connections per second...

(Note that for anything related to RSA, running an x86 CPU in 64-bit mode is a huge win -- that's what I do with my cheap server, by the way. In 32-bit mode, divide the figure by 3 or 4; this would still be quite respectable performance.)

Also, SSL/TLS has a feature known as "abbreviated handshake" which is about a client connecting again and reusing the asymmetrically exchanged secret of a previous handshake. See section 7.3 of the standard. The abbreviated handshake involves symmetric cryptography only, no RSA. Note that, in practice, the best thing about abbreviated handshake is that it implies less network packets and lower latency; the lower CPU usage is nifty but not so visible when actually measured.

Assuming that you nonetheless find the asymmetric part of SSL to be huge on the CPU budget, your best bet will still be a "plain RSA" cipher suite, although there could be a tie with ECDHE cipher suites (but the only elliptic curve which is decently supported by existing clients is the P-256 curve, which is fine but somewhat an overkill if you just aim at 80-bit security).

SSL/TLS also uses symmetric cryptography, and that one can use some CPU, too. An x86 CPU is more than powerful enough to encrypt all data which can go through a 100 Mbits/s link, but you can have some savings if you choose your algorithms properly. In practical terms, this means: use AES or RC4, not 3DES. AES will be exceptionally fast and cheap if your CPU offers the AES-NI instructions (and if your SSL implementation uses them, of course).

For the hash algorithm, MD5 is somewhat faster than SHA-1, but SHA-1 can already process 240 Mbytes/s (mega-bytes, not megabits) on my cheap AMD CPU.

So this points at TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA to be the cipher suites of choice for who wants to get the most connections per second for the least CPU. Or possibly TLS_ECDHE_RSA_WITH_RC4_128_SHA or TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, which will be less widely supported, but will give you Perfect Forward Secrecy, which can be a nice thing to have.

This being said, performance can depend a lot on architectural details and the exact operation environments, therefore you shall measure. Try it and see if changing the cipher suite makes any actual difference. Remember that performance has often a lot more to do with the amount of efforts invested in the protocol implementation, than with the intrinsic merits of the algorithms themselves.


How to protect from WPAD attacks? If you are in a Windows network, and you basically connect to a website ; And there is an attacker on Linux who changes the hostname to WPAD and configures WPAD.dat in his system, all your PC's traffic can be captured (or) spoofed.

WPAD.dat - Something like:

function FindProxyForUrl(url, h){

    return "FAKE PROXY";

}

As a client device, simply turn off the "Automatically detect proxy settings" feature in Internet Options. This prevents the browser from trying to look up a location for the wpad.dat or proxy PAC script.

If you want to protect poorly configured devices on your network, set a DNS entry for WPAD and blackhole the traffic.


Securing admin login page Is it secure to use a familiar URL such as website/admin or should I use a different name so it would be harder to find the page in the first place (assuming no traffic monitoring)?
I'm using SSL. Do I need to further encrypt the admin password using RSA per sy? Two factor authentication too? Is it overkill?
Should I use something like a VPN to have a fixed IP and limit the login page to that IP? (What will I do if I no longer have that VPN?)
Any other tips, pitfalls, security risks that I need to look out for (apart from brute forcing)?

I can't help but feel this is a bit too broad as your asking 3 rather open ended questions but I'll attempt to answer each in turn:

Using a common URL for an admin area shouldn't be a problem - yes common "hacking" scripts will attempt common exploits against the common ones but that shouldn't mislead you into thinking you should hide the address or that you have any real appreciable gain in security from doing so. This is a case where Kerckhoffs's principle applies - you must assume a starting point that the attacker knows where the admin URL is.
Encrypting (or more specifically cryptographically hashing) the password using something like bcrypt should be a standard step, as you point out ssl will protect the password in-transit between client and server but hashing the password protects it at rest. Using SSL in the login process does nothing to protect you from the attacker who compromises the database and gets all your plaintext passwords.
Can't really answer this without knowing the use-case for the system. If it's only ever required to connect from one connection then VPN with a fixed IP can add an extra layer, with the risk that you point out that if you lose access to that connection and have no other way to access the system enough to change that IP restriction then you're kind of screwed. There are plenty of ways to put failsafes in for this sort of scenario but without much more detailed information on the specifics of the system and it its intended purpose it's far too broad a topic to address here.


How to securely store sensitive information? I tried finding answers on my own before submitting this question, but I failed.

I have banking information which I would like to securely share with my wife. For some reasons she can't just go to a bank and access those accounts.

So I am thinking to write up a document which will contain all of the necessary information.

I need a way to store it securely somewhere accessible. Preferably in the cloud. Of course I wouldn't want to store it just in plain text.

The only way I can think of is putting the document in the password protected ZIP file.

As soon as I hear store sensitive information, I think of password managers. That is what they are made for, and some of them do it very nicely. For example the excellent Keepass allows to store additional informations associated with a particurlar account. For example, you could create a dummy account to store a Visa card number, its PIN, validity date and 3 digit key.

You can use only local storage and synchronize different databases provided they can be visible from one machine. For example it is trivial to synchronize a desktop or laptop, a tablet and a smartphone. Synchronization is indeed one of the nicest features of Keepass.

You can also have the database somewhere in the cloud, and use a random file of several kbytes as a key that you securely store on each device where you want to use it. You can even combine that key file and a password for higher security (something you have and something you know).

The only drawback is that whatever the key is, it must be the same for all devices or users if you want to share the sensitive information. And as we all know a secret that is shared between more than two persons/devices is no longer a secret. But anyway, it would not be worse than an encrypted zip file, and the key file would even add some security because it will resist by design to dictionary attacks, and even brute force will be hard to use because the entropy of the key file is high.


What are the drawbacks to automatically deleting web server access logs? What would be the downsides to either disabling or automatically deleting web server access logs that are older than 7-10 days?

I'd like to limit how long I store personally-identifiable data (IP address) for my visitors but would also like to strike a balance with regard to security.

Would I be losing anything important if I were to disable logs or just didn't notice something wrong with the site until after the logs had been deleted?

Disabling logs may deny you the ability to properly audit security events when they are noticed. If erasing IP addresses is a concern, there is an approach that will allow you to retain useful information without storing the actual IP address - tokenisation. You could convert the IP addresses to opaque hashes that allow you to track a source IP's activity in the logs without knowing the exact IP. If an IP is found to be behaving in a malicious way, you could then check recent logs/new connections for any IP address that hash to the same output. At the least, you will have a better chance of reconstructing what went on.

You may also wish to consider log aggregation solutions.


Best practice for Users to avoid fraud for Direct Debit enabled bank accounts? Direct Debit or automatic debit transfer system or Bankeinzug (German), seems a common/convenient way to pay in (online shops in) many countries available for many banks.

https://en.wikipedia.org/wiki/Direct_debit

Thereby, ANYONE who gets "authorized" (or knows) your debit card credentials (BIC, IBAN, Account Holder Name) can withdraw a certain amount of money...

The authorization mechanism behind it is often trivial and not secure.
In the best case it involves the owner to sign a contract at the bank, in the worst case its a checkbox in some online shop...

To the best of my knowledge, the "security-mechanisms" behind it are the following (for some German banks):

debit card credentials must be known (actually not a secret)
Transaction can be rolled back up to ~6 weeks after it happened
Max. transaction amount ~100€

So please help me here, If I see this correctly, but this seems very vulnerable to fraud...
If so, please tell me a systematic/best-practise approach of mitigating it or some form of automatic fraud detection and notification that could be applied.

I know that some services like PayPal are using a form of authentication before the direct debit by challenging the bank account owner with a OTP in a small (1cent) transaction he has then to enter in the service....why is this not standard for direct debit.

The system is safe by design: the best practice is to simply use the system's built‑in protection.

Unlike debit cards, you can ask your bank to enable a safe whitelist of IBAN account numbers allowed to withdraw from your IBAN. Any attempts to initiate a debit from an unauthorized account will result in payment rejections.

Though this option isn’t always available for online-only banks.


Should I encrypt Blutooth communication? I'm making an Android app which needs to safely communicate with PC app over Bluetooth. I'm going to use RFCOMM for that purpose. Since apps will exchange user authentication details, there should be no possibility to get unauthorized access to them. Is level of security of Bluetooth high enough or should I encrypt the traffic anyway?

If yes, what would be the best way to do that?

Also is it a good idea to use RFCOMM?

Secure "enough" really depends on your use case.

Security is often a tradeoff between cost, time, user experience on product side but also cost, time and gain on the attackers side.

I assume your app is kind of product. So from marketing side, do you need to write "most secure ecryption possible" on your product or just "state of the art encrypted data transfer" ? Does anyone care?

How much could an attacker gain from sniffing the data? How much knowledge, time and money would it cost him?

Is your product usually used in a home environment? Then an attacker would maybe need to wait and sit very long in front of your house to sniff data at all. Not so realistic. Is your app usually used in front of an ATM? Then an attacker would know where to wait.

And then even if an attacker was able to sniff the raw data, can he decrypt it? I agree with comments above: If you can ensure that L3 with ECC192 will be used, a successful attack is very unlikely today.

Is the encrypted data of any value if decrypted in 10 years or so? If yes, maybe additional encryption would make sense, but I see rare use cases for that.

Using RFCOMM or not has little implucations on the security I think.


Is showing the package name(Android)/bundle ID(ios) a security risk? Suppose I release an app and accidentally publish the package name/bundle ID of the app which is suppose to be shown in development only, in a page. Is there any security concern that arises from this?

Does the package name need to be kept secret

No.

Here is a link to one of my apps:

https://play.google.com/store/apps/details?id=uk.co.jrtapsell.appinfo&hl=en

(Link purely for example, it was found on the first page of google when the app name was searched for)

You can see that google provide the package name in the URL, so even if you hid it, opening the store page for an app would give it out anyway.

Do bundle IDs need to be kept secret

No.

Following the steps here, you can get the bundle ID from the app link, so it would appear that it does not need to be kept secret.

  Find the app online (Google for the iTunes link). For this example we use Apple Pages: https://itunes.apple.com/app/pages/id361309726?mt=8.
  Copy the number after the id in the URL. (Here: 361309726).
  Open https://itunes.apple.com/lookup?id=361309726 where you replace the ID with the one you looked up.
  Search the output for "bundleID". In this example it looks like this (next to a bunch of other data): "bundleId":"com.apple.Pages".

  So for Apple, the bundle ID is com.apple.Pages.


What is the current EU standard for data destruction? I have been hunting around for a couple of weeks trying to find what the current standards for sensitive data destruction in the EU/UK are.

If you look at the destruction companies they have several answers BS EN: 15713:2009 comes up a lot, but so does DIN 66399 which some places put an EN in front of making it a EU standard.
on top of that, a lot of places refer to the UK HMG IA 5 standard, but they have been superseded. The latest standard I can find is the April 2014 CPNI Standard secure destruction of sensitive information.

But nothing seems to be as definitive as FIPS 880-88r1 and the CMRR research from UC:SD, but some of it contradicts these.

I'm not 100% sure what the EU laws and guidelines would be however; I suspect it's left to the member states to decide what to issue in regards to deletion of personal information. with that said I found a PDF from the UKs Information commissioner’s Office (ICO) and they state in this document that...

  ...the ICO will adopt a realistic approach in terms of recognising that deleting information from a system is not always a straightforward matter and that it is possible to put information ‘beyond use’, and for data protection compliance issues to be ‘suspended’ provided certain safeguards are in place

  information has been deleted with no intention on the part of the data controller to use or access this again, but which may
  still exist in the electronic ether. For example, it could be waiting to be over-written with other data.

  information that should have been deleted but is in fact still held on a live  system because, for technical reasons, it is not possible to delete this information without also deleting other information held in the same batch.

and in addtion to this in the next section it states.

  The ICO will be satisfied that information has been ‘put beyond use’
  if not actually deleted, provided that the data controller holding it:

  is not able, or will not attempt, to use the personal data to inform any decision in respect of any individual or in a manner that affects the individual in any way;
  does not give any other organisation access to the personal
  data;
  surrounds the personal data with appropriate technical and
  organisational security; and
  commits to permanent deletion of the information if, or when, this becomes possible.

So I suspect that they, themselves do not know the best approach so are leaving it vague. As long as you make the effort to show you deleted it and tried to make it un recoverable then I guess they are happy with that. As you and Graham Hill (comments) suggested, I would go with an industry standard such as BS EN:15713 or DIN 66399.

Accessed 15 May 2016

ICO Website for newest guidelines (UK)

ICO PDF on deletion


Why would HTTP client only send authentication headers once an unauthenticated request was rejected? The default usage of HttpClient and HttpWebRequest .NET classes is setting Credentials property and then asking the class instance to perform an HTTP request. If the target requres Basic authorization the following happens (those classes do this under the hood and Fiddler shows what's going on):

the first request is sent without Authorization header
the server declines and responds with HTTP 401
the client resends the very same request this time with Authorization header containing the properly encoded data from Credentials property

and this is the default behavior. So unless the user validates his application and takes extra steps every request is sent twice - the first one is universally rejected.

My question is - what's the reason for such default behavior? The client class has its Credentials property set so it kind of assumes the user wants to use those credentials for authentication. Why not just send the appropriate header with the first request? Would doing the latter somehow compromise the client?

This behaviour is specified by RFC2617. The reason for the extra round trip is that the server can request different kinds of authentication: basic, digest, etc. If you know in advance that the server takes basic authentication, then as you say, you can save a round trip. But that isn't the default, and I think the .NET libraries are right to expose this as they do.


Why can an encrypted private key be brute forced? When using SSH keys to authenticate to a server for remote access, why is it possible to devise the true key and therefore the passphrase from an encrypted private key, without checking each guess of the passphrase against the server to see if it authenticates?

I understand that the passphrase is only used to decrypt the key and not sent to the remote server, but I don't understand why it is easy to tell the result of the correct decryption from the result of an incorrect decryption. If that was impossible (or implausible), surely SSH keys would be more immune to bruteforcing and therefore stronger?

I see it as a weakness, but I barely understand the maths behind public key authentication, so I'm assuming that there is a reason I have missed but you far cleverer people are aware of.

Plaintext that consists of an RSA private key can be easily recognised, because it satisfies certain mathematical properties.  In particular:

d = e^-1 mod (p-1)(q-1)

This means that given the public key and a candidate d, you can calculate

d . e mod (p-1)(q-1)

If the result is 1, then you have found the correct key.

The solution is to use a strong passphrase for protecting your private keys.


How much is ASLR effectiveness impacted by different ABIs? Linux has multiple x86 ABIs: ia32, x32 and x86_64.

ia32 and x32 both use 32 bit addresses for addressing and x86_64 uses 64 bit.

Now, the question: Since the size of the memory space should affect how much addresses could be randomized, how much does this impact the effectiveness of ASLR, and how much does it matter in practice? Similarly, does the number of available registers somehow matter for ASLR effectiveness?

May be this will give you more information :

Wikipedia

  Address space layout randomization

  Effectiveness

  Address space layout randomization is based upon the low chance of an
  attacker guessing the locations of randomly placed areas. Security is
  increased by increasing the search space. Thus, address space
  randomization is more effective when more entropy is present in the
  random offsets. Entropy is increased by either raising the amount of
  virtual memory area space over which the randomization occurs or
  reducing the period over which the randomization occurs. The period is
  typically implemented as small as possible, so most systems must
  increase VMA space randomization.

  To defeat the randomization, attackers must successfully guess the
  positions of all areas they wish to attack. For data areas such as
  stack and heap, where custom code or useful data can be loaded, more
  than one state can be attacked by using NOP slides for code or
  repeated copies of data. This allows an attack to succeed if the area
  is randomized to one of a handful of values. In contrast, code areas
  such as library base and main executable need to be discovered
  exactly. Often these areas are mixed, for example stack frames are
  injected onto the stack and a library is returned into.

ASLR makes the job of exploitation much more difficult but not impossible. I don't think the number of register increases the effectiveness of ASLR. If you practice vulnerability exploitation you will see that jumping/finding to the right address in memory to your shellcode is very difficult with ASLR even with NOPs. If the stack is not executable (DEP) its even more difficult and return to libc technique is used.

Another similar topic

Additional information also here


What is the best way to encrypt a JSON object in Java? I have a JSON array:

JsonArray people;

Which holds JSON objects representing people.

Currently I am saving them as plaintext in a json file.

try {
    OutputStream out = new FileOutputStream('storage.json');
    JsonWriter writer = Json.createWriter(out);
    writer.writeArray(people);
    writer.close();
}

However I want these files to be encrypted so that they are worthless without the key to decrypt them.

What is the best way to do this? Should I encrypt the JSON array object or can I just encrypt the entire array before writing it? What is the most recommended Java crypto functions that I should use to do this?

There are many ways to do this.

I would encrypt the JSON at a entire file level rather than encrypting content within it.  The alternative is complicated and gives no meaningful security advantage.  I recommend using an AEAD cipher (my present recommendation is AES-256 with GCM: aka AES/GCM/NoPadding with 256-bit keys).  To use GCM you need to be on Java 8 or later.  To use AES-256 with an Oracle JRE you will need the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files installed as documented.

You should make sure to set the authentication tag to include information about location and use (the true filename is a good start) to make it hard to rename or substitute other versions (a form of at-rest replay attack).

However, encrypting the JSON content isn't a complete solution.  It just moves the ball a bit.  If the attacker still has plaintext access to the private key then it won't be effective.

To protect the private key plaintext you can use a KMS (Key Management Service) on a separate system.  That keeps the private key out of memory access on the machine with the encrypted JSON file.  You submit the encrypted file content to the KMS to be decrypted on load or vice versa on store.

With those in place you can effectively protect the file from offline attacks (ex: disk image analysis, machine image analysis, backup theft, media theft).  Without further defenses, the content of the file is still subject to online attacks of the memory of the machine itself.


Why should I log successful log-ins to my server? I was arguing with a friend about logs in user logins. I think that logs means a big audit source for IT audit professionals. Why should I log successful log-ins to my server?

It's so important log fail attempts to log because I can realize if some malicious person wants enter to my system using brute force, but why record successful logs?

There are a few reasons that come to mind. Much of this depends on what your app does. Online banking? You want to log more than a community forum with no sensitive information or monetary value. Business app vs public?

1) IP address the user logged in from. This would provide some information should the account be compromised, and could help track down the offending person.

2) Determine if the user was able to login after failed login attempts. For instance, 9 failed attempts followed by a successful one means something very different than 9 failed and then no successful login.

3) Determine when the user last logged in, for various reasons, including whether they are actively using their account. 5 years since the last login? Not an active user.

4) If this is a business app, then you do want to log whether somebody accessed the application or not. For instance, if we know Bob is out of the country but then access the application, that could indicate something fishy. "Something fishy" will entirely depend on the application and your business.

Those are a few things that come to mind. Personally from my experience, I have used successful logins numerous times to help with internal and external investigations.


How to check if a port can be accessed from the outside I want to be sure that the firewall protecting the intranet is effectively rejecting/granting access to a port. I have no access to the firewall nor any other external machine.

Is that possible at all?

I was relying on a web service I had setup on a machine outside, but I wondered if there's some other way. Is it possible to have a special TCP package sent with a modified header so it will be returned to a different port on the same machine?

EDIT:
It's just one port, nmap is not really required.

An example of what I meant by special TCP package:
The internal machine starts a TCP connection on port A to the outside but forges "somehow" the package so that the firewall recognizes the connection to the outside is being established from port A but the remote machine answers to port B. So perhaps the firewall assumes the ACK/SYN is the start of a new connection from the outside and treat it like such... would that be even thinkable?

EDIT 2:
I've tried using the PORT command of FTP to tell a remote FTP server to send the data to a specific port on a specific machine. I couldn't manage to get it work:

ftp> quote PORT 127,0,0,1,178,148
---> PORT 127,0,0,1,178,148
200 PORT command successful. Consider using PASV.
ftp> get start_main_ws
local: start_main_ws remote: start_main_ws
ftp: setsockopt (ignored): Permission denied
---> PORT 127,0,0,1,155,88
200 PORT command successful. Consider using PASV.

It breaks and it automatically send a different PORT number which just works. It does look promising even though I can't make it work.
(by the way this is just a local test as a proof of concept)

No, there's no way to do an external port scan without actually having an external machine.

I would suggest grabbing an Amazon EC2 instance (because it's cheap) and running nmap from it.


Accessing over a VPN both sites that know your real identity and sites you want to stay private from Goal 1: access certain "anonymous" sites that you don't want to provide your real identity, IP or location to.

Goal 2: access "regular" sites that do require or have your real identity, such as your bank or Facebook.

All sites use end-to-end encryption over HTTPS, so packet sniffing isn't an issue.

Let's say you're using a VPN that you trust to not keep logs, and is located in a jurisdiction outside of the Five Eyes. Unless you use split tunneling, all your traffic will go through the VPN - both to regular and anonymous sites.

Is it a bad idea to access over the same VPN both sites that know your real identity and those that don't? What kinds of attacks could expose your identity to a) the anonymous sites, b) the attackers?

If one of the "regular" sites is subpoenaed, they can hand over your IP as well as the IP of the VPN(s) you've used to connect to them, but if you trust your VPN provider to not keep logs, this doesn't seem like a problem. If an anonymous site is subpoenaed for all users who've connected from that VPN IP, you have plausible deniability, since the VPN's external IPs are shared.

Is it a bad idea to access over the same VPN both sites that know your real identity and those that don't?

From a hyperparanoid perspective yes. You will likely have the same visible IP for both sites. Whilst usually you would expect other users to be present at the VPN IP it still makes pairing up your requests easier.

  What kinds of attacks could expose your identity to a) the anonymous sites, b) the attackers?

Two obvious ones -

Browser Fingerprinting. This is surprisingly accurate - https://amiunique.org/
Packet matching. I.e. someone with wire access to traffic entering and leaving the VPN can use statistical methods to pair the packet you send into the VPN with the packet leaving the VPN for the remote server (and vice versa).


Are password complexity rules counterproductive? In creating a login for this site I chose a nondictionary password that would be extremely hard to guess, but easy to remember.

I was told that it did not meet complexity rules.

After several iterations of this, in frustration and just for the hell of it I tried 'Password1' -which was accepted.

Raises the question how many non-IT people do likewise when faced with this situation? Golf1? Mercedes1? Metallica1? Guessable if you know the guy? Yes.

At work we issue passwords rather than allowing users to set them. We use nonsense words. For example, artifubulist. There is software to generate such words. Such passwords are surprisingly easy to remember but presumably, very hard to bruteforce. Unfortunately, default password complexity rules on Microsoft servers prevent this simple but secure option being used. Unless of course you change the policy.

Thoughts on this welcome.

Password complexity rules are counterproductive -- for the most part.

Password complexity rules:

make users angry, and thus uncooperative and likely not to enforce password protection rules that only they can enforce;
incite user to choose creative workarounds to go past the password rules
are often grossly incomplete, and don't filter out some classic or soon-to-become-classic passwords which users find as workarounds, see point 2 above. For instance "Password1".

The only "reasonable" password complexity rule which I have encountered yet is a minimal password length. Requiring passwords to have at least 8 characters is not a hardship on users, it is understandable, and avoids passwords which are necessarily weak since they are in range of the most stupid of exhaustive searches.


Is this integer overflow vulnerability exploitable? Is this integer overflow exploitable and if the answer is yes,  how can i exploit it?

char buffer[20];
int len = atoi(argv[1]);
if(len < 20)
  memcpy(buffer,argv[2],len);

If I set len to -1 the application crashes, because the number of bytes to copy is too long and there is a segfault. But is there a way or method to exploit the vulnerability?

Yes

You don't need to use -1, any value larger than 20 will allow you to overflow the buffer.

It will depend on the next instructions and the mitigations set by the compiler, but from this point on you can probably overwrite the return address and execute a shell code provided as the second parameter.


Targeted acoustic keylogging attack prevention To what level could this be applied to? Could someone record keystrokes on a keyboard and in combination with typing habits start to put together a picture of what the user is typing?

If this is indeed true what steps could the user take to help mitigate this?

I know that these attacks have been demonstrated in printers but I'm wondering to what extent could they be used?

In my opinion acoustic cryptanalysis is more of a proof of concept then to be used in real applications.

What is possible to do?

A few years ago guys from MIT (if I am not wrong) were able to log every keys on a mechanical keyboard using an Android/IOS phone application and just by placing that specific phone near the keyboard.

Things you can do to mitigate:

Use on screen keyboard.
Ensure that there aren't any other device near your computer
Use Snowden type pillow even if it's a bit paranoia (or not)
Use smart card/ smart usb authentification
Randomly generate frequencies in the 400-12000 Hz range (which seems to be the one containing keystrokes sounds) and use headphones


Things to remember while building a password manager I want to build a simple password manager for desktop whose sole purpose is to store the passwords that can be read by the user as and when required.

I am not considering any fancy features such as autofill, cloud storage, password sharing etc.

Its purpose is to just store the passwords. What are the guidelines to build such secure password manager?

I agree with Mike Scott's comment that it's best to use something which is already open-source which has gone through all the research and so on. If your doing the project for learning and personal usage then start off with basics such as:

If you support clipboard don't forget to clear it during application been closed or after a set time period.
Don't leave text in memory after it's usage
Do good amount of research into encryption for your database and enforce a good password policy
Support keyfiles for higher level of security
Don't store any confidential information as plain text on disk
Don't support any network related APIs or if you do make sure you validate all your buffers to avoid any remote buffer overflows.

You could go alot more into malware targeting your software using APIs such as FindWindow to read the strings out of your application and code injection using CreateRemoteThread but I'm not too sure of how complexity you want to secure the password from been stolen via malware.

I'd recommend you look into the code of an reputable password manager which is open-source as they will of done the above and more.

I know this list doesn't cover everything but I hope it's a good starting point for you.


Is there a way to specify PHP escape method when using SQLmap? I'm helping a collegue of mine to test if his website is completely SQLi-proof. It looks promising, but i'm trying to make sure, and by chance I know he's using pg_escape_string to sanitize his POST input.

This may be a stupid question, but I'd like to know, if there is a way to specify the escape method for SQLMap?

Also as long as I'm here, I'd like to ask for opinions which would be the best escape method to use (PHP-PostgreSQL combination) is pg_escape_string sufficient or should he use something else?

Have a look on PHP PostgreSQL Prepared Statements. It will escape your variables just fine and it will help you with forgetting to escape something, or double-escape.


Encrypting Fields in Database I'm working on an ASP.NET web application that will have to store sensitive information. I would like to encrypt the sensitive fields to protect against any possible SQL injection vulnerabilities. However, I also will need to report on these fields. For these reasons, I've excluded transparent database encryption (since it wouldn't provide protection against SQL injection) and application layer encryption (since it would make it hard to report against the data) and I'm left with database level encryption.

My plan is to use SQL Server's EncryptByPassphrase function, with an SSL connection to the database to protect the passphrase over the wire. The key would be stored in the web.config, protected by the Windows Data Protection API at the machine level.

Is this a good plan? What are the potential vulnerabilities?

Yes, it's a good plan, but there are still a number of potential vulnerabilities.  Really, the only attack that you're mitigating is the attack you mentioned, the ability to grab the cleartext data with an arbitrary SQL statement.   You're not mitigating any other attacks, for instance, a malicious user who uses SQL injection to elevate their privileges within the application so that they can view a pages where the application expects to display this date in cleartext.

So, the real solution is defense in depth.   This is a fine part of that solution (and indeed sensitive data should be encrypted at rest) but in order to effectively protect it you also need additional safeguards, such as:

General SQL injection protection strategies such as only allowing access to the application user via parameterized stored procedures and denying access to the underlying tables completely.
Protection against attacks relying on arbitrary code upload and execution
Protection against XSS and session stealing attacks that might allow a malicious user to capture authentication cookies from an administrator.

The data is only safe as the weakest link in the overall application security, so remember that direct attack on the data itself via SQL injection is not the only thing you need to think about in order to protect it.


What happens when I encrypt something with my RSA Public Key? I know encrypting something with my private key is used for signing. To prove that the message is indeed coming from me.
But what about if I sign something with my public key? That would mean that only I could decrypt it with my private key.
Suppose I did this and I sent over my ciphertext (encrypted with my public key) over to somebody. Will he be able to decrypt it?

There is a common misconception that signing a message is the same as encrypting the message with the private key.  This notion is fundamentally incorrect, as pointed out by Thomas Pornin at If the public key can't be used for decrypting something encrypted by the private key, then how do digital signatures work?.  As Pornin explains, encryption/decryption and signing/verification are in fact two different algorithms.  A private key can be used to decrypt a message that was encrypted using the correspoding public key, or to sign a message; but a private key cannot be used to encrypt a message.
By the same logic, the notion of signing a message with the public key is also fundamentally incorrect.  A public key can be used to encrypt a message, or to verify a signature made on a message using the corresponding private key; but a public key cannot be used to sign a message.


What are the security implications of enabling WINRM on all domain members? As Powershell becomes more and more popular, it appears that using WINRM may end up being a better option than using PSEXEC from SysInternals for remote management. Given that WINRM is disabled by default, however, I wonder what type of security holes it would create to enable the service on all domain members. Obviously the attack surface would be increased, but would it be any worse than the default administrative shares or enabling SSH?

"Security holes" I think is a bit subjective.  You need local administrator credentials to connect to WINRM.

It does increase the attack surface of the system, and it is disabled by default because it's not one of the top n services used by most administrators.

WINRM uses SOAP (WCF), which uses HTTP.sys, which makes it a prime target for attack.

Is it insecure? No. Is it insecure if it's enabled and it's never used? Not really, but there could be a vulnerability found in the future, and it would make you feel kinda dumb for enabling the thing when you don't ever use it and get attacked because of it.

If you are okay with that particular scenario, then sure it's no worse than the default shares. But it all depends on what kind of environment you are in. If you need or want to use WINRM for management of your machines, then you are probably fine to start it.


Company name is used in Dropbox invoice scam People, not employees or users, just ordinary people with no relation to us, have been getting scam emails, prompting them to open and download a link from Dropbox.

I think this link contains files that are infected with ransomware.

What should we do to mitigate this problem? We don't want our company to be associated with this scam. Are there any steps we could follow?

Our company is based in Norway.

In practical terms:

try contacting your local CERT/CSIRT/CIRT (https://www.cert.org/incident-management/national-csirts/national-csirts.cfm) and make them aware of the issue
make sure you have some information available for potential victims, that explains you are aware of the issue, and are trying to do something. Consider making this information visible in places like Facebook/Twitter/wherever else you think people might be going to find out what is happening to them
try contacting your local police and reporting a violation of your commercial trademarks (or whatever analogue for that might make sense)
try contacting Dropbox, and see if they can do anything about the link, and whether they might also be prepared to link to your public info about the issue (total shot in the dark, but you never know).
if you think there is a chance it could help, consider contacting the relevant Network Information Centers (france: https://www.afnic.fr/, germany: http://www.denic.de/en/) and asking for their help. It doesn't sound like you are in the best position for that, but if the mails were trying to spoof/mimic your domain in some way, you might have some traction.

I suspect putting up a statement would be your first priority, as would be contacting Dropbox.

While I suspect (based partially on previous, somewhat similar experiences) you will have some difficulty with getting the police to take up your issue, I think that if you try and avoid pointing too much to the ransomware aspect, and focus on the commercial harm being done, you might at least be able to get a complaint recorded (this might be useful, or necessary, for the CERT to help).

The email itself is purporting to be an invoice from your company, so I do think you have pretty good grounds (I am not a lawyer, and even less so in Scandinavia) for reporting this as a commercial crime. This will probably not really help that much in practice, but is due diligence, and having a police complaint may be useful when dealing with other entities.

I think I would try and contact the local CERT first, if only because they might be able to help point you in the right direction with regards to recording a complaint with the police.

Do keep in mind, too, this sort of thing is far from uncommon, and all kinds of companies are regularly 'targeted' in this way - the ISC (https://isc.sans.edu) has some variation of this scam, often involving a big name multi-national, reported on most weeks.


Modify Certificate Subject using OpenSSL x509 Command I'm building a CA based on the OpenSSL command line tools. I don't want to use the openssl ca tool and its file based database though, instead I create certificates using the openssl x509 tool directly and assign a random serial. (I want to manage revocations, serials and policies myself.)

This all works, the problem is that the subject line is copied directly from the CSR into the certificate when issuing a new certificate. I want to be able to override the subject. Unfortunately the x509 command does not provide a -subj <arg> parameter like the ca command does.

As a workaround, I tried to rewrite the CSR itself. I can easily change the subject using openssl req -in oldcsr.pem -subj "newsubj" -out newcsr.pem. But then of course the CSR signature is not valid anymore and openssl x509 complains that the "signature did not match the certificate request". And I didn't find an easy way to ignore the signature.

Is there a way to override the subject of a CSR when generating a certificate, without using the openssl ca tool?

My example:

Generate a self-signed certificate (and private key)

$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -sha256 -keyout mydomain_rsa.PEM.key -out mydomain.PEM.csr -subj "/C=CN/O=Company Inc."
   Generating a 2048 bit RSA private key
   ..........................+++
   ........+++
   writing new private key to 'mydomain_rsa.PEM.key'
   -----

View the subject

$ openssl x509 -noout -serial -subject -in mydomain.PEM.csr
  serial=CCC8F2F4B4BEDBAC
  subject= /C=CN/O=Company Inc.

Modify the subject

openssl req -x509 -in mydomain.PEM.csr -subj '/O=Company2 Inc.' -key mydomain_rsa.PEM.key -out new_mydomain.PEM.csr

View the subject of the new certificate

$ openssl x509 -noout -serial -subject -in new_mydomain.PEM.csr
  serial=A873BD71BCD0DFF7
  subject= /O=Company2 Inc


How to transfer securely a file between servers? Let's say I have two Linux servers. One containing a desktop app database (running on a local network) and a webserver.

I want to automatically transfer each hour a database file (with a size of a few  MB) from the local server to the web server to make updates.

The information needs to be encrypted and the server has to be authenticated in order to make the transaction.

I was thinking on SSH File Transfer protocol. My questions are:

Is it the best option?

What other options do I have?

What existent library / script can I use to make the task automated? (in both servers)

The best way is to use SCP with SSH keys. It's some of the best encryption commonly available, designed to work without intervention, very reliable, easy to script, and extremely well documented. Set up your keys and a cron job.

The only other good option is to change your application design to sync the data over an encrypted channel, such as a mysql slave server using SSL (actual solution depends heavily on your app).

For scripting it, write up your own shell script:

#!/bin/sh
SOURCE="/path/to/source"
DEST="user@ip.ad.dr.ess:/path/to/dest"
KEY="/path/to/sshkey"
LOG="/path/to/logfile"

scp -i $KEY $SOURCE $DEST >> $LOG 2>> $LOG