Security

1232 readers
1 users here now

A community for discussion about cybersecurity, hacking, cybersecurity news, exploits, bounties etc.

Rules :

  1. All instance-wide rules apply.
  2. Keep it totally legal.
  3. Remember the human, be civil.
  4. Be helpful, don't be rude.

Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 2 years ago
MODERATORS
76
 
 

cross-posted from: https://lemmy.capebreton.social/post/397946

Authors:

Lorenzo Neil, North Carolina State University; Harshini Sri Ramulu, The George Washington University; Yasemin Acar, Paderborn University & The George Washington University; Bradley Reaves, North Carolina State University

Abstract:

Users have a wealth of available security advice


far too much, according to prior work. Experts and users alike struggle to prioritize and practice advised behaviours, negating both the advice's purpose and potentially their security. While the problem is clear, no rigorous studies have established the root causes of overproduction, lack of prioritization, or other problems with security advice. Without understanding the causes, we cannot hope to remedy their effects.

In this paper, we investigate the processes that authors follow to develop published security advice. In a semi-structured interview study with 21 advice writers, we asked about the authors' backgrounds, advice creation processes in their organizations, the parties involved, and how they decide to review, update, or publish new content. Among the 17 themes we identified from our interviews, we learned that authors seek to cover as much content as possible, leverage multiple diverse external sources for content, typically only review or update content after major security events, and make few if any conscious attempts to deprioritize or curate less essential content. We recommend that researchers develop methods for curating security advice and guidance on messaging for technically diverse user bases and that authors then judiciously identify key messaging ideas and schedule periodic proactive content reviews. If implemented, these actionable recommendations would help authors and users both reduce the burden of advice overproduction while improving compliance with secure computing practices.

Open Access Media USENIX is committed to Open Access to the research presented at our events. Papers and proceedings are freely available to everyone once the event begins. Any video, audio, and/or slides that are posted after the event are also free and open to everyone. Support USENIX and our commitment to Open Access.

Neil PDF
View the slides

77
 
 

Why Decentralization is the Only Way to Prevent Cybersecurity Breaches?

1/ A decentralized network is built by people, where individuals function as nodes within the network.

2/ There is no central server that stores data in a single location; instead, all data is distributed across random devices/nodes within the decentralized network.

3/ Data can only be decrypted using a unique private key specific to each user.

4/ Messages are sent with end-to-end encryption (E2EE) within a peer-to-peer (P2P) decentralized network, bypassing the need for a central server, unlike centralized platforms such as Telegram or WhatsApp.

The absence of a central server translates to no centralized data storage, which in turn means no potential entry point for hackers to exploit and compromise data, thus preventing data breaches.

Three decentralized tool that I tried:

  1. SimpleX:
  • Simply a decentralized messaging tool, safer than Session
  1. Nostr:
  • Fully decentralized social platform
  • Full of spam, hard to use compares to mastodom.
  1. WireMin:
  • Not open sourced (if they are open sourced, it will be my top choice.)
  • A combination of mastodon and Session
78
 
 

I think the title of the talk is click-bait, but the content is interesting otherwise. The talk is roughly 40min + 15min Q&A

79
80
81
82
 
 

As we often report here, it’s common for tech companies to help each other improve their security systems by sharing zero-day exploits found by security researchers. Google, for example, does this a lot. But recently, an Apple employee reportedly found a zero-day exploit in Google Chrome – and that bug was never reported to Apple by that person.

83
84
85
86
87
 
 

cross-posted from: https://programming.dev/post/160750

Dominick Baier's talk is a great introduction to the often confusing world of OAuth. There are many good resources about details of a given flow, but the challenging thing is which flow to use for what.

88
89
 
 

Yeah, uh.... at least ublock's EasyPrivacy list catches most of them