Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
biboumi
biboumi
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 98
    • Issues 98
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 12
    • Merge Requests 12
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • louiz’
  • biboumibiboumi
  • Issues
  • #3457

Closed
Open
Opened Jul 05, 2021 by southerntofu@southerntofu

Maybe salt hashed JID in identd requests?

Reading the code, i realized that biboumi gateway transmits a raw hash of the user JID to the IRC server when identd service is enabled.

I understand in some situations, it is desirable for the biboumi server to be transparent to the IRC server (for reputation), and that a hash of the JID is useful to ban individual users not the whole bridge. However, i argue a simple SHA1 hash defies expectations:

  • when you set biboumi to broadcast user JIDs, then the privacy implications are clear
  • when biboumi is sending a hashed version of JIDs, then it should not be trivial for a passive attacker, or the remote IRC server, to figure out who's who

Simply using sha1 to hash the JID opens the way for side channels to reveal JIDs of people despite it not being obvious from the configuration. For example, it becomes trivial for someone with a huge list of JIDs (eg. obtained from a compromised XMPP server) to hash them and make correlations.

So i'm proposing two things:

  • use a more modern hashing function that is not broken yet (SHA1 has collision attacks ongoing and is deprecated in most software)
  • include a salt in the hash, that's unique per server and not guessable by a passive attacker ; it may be a random value generated once server side, or even just /etc/machine-id if this is portable across systems
To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: louiz/biboumi#3457