Wanderer项目中的Komoot同步加密问题分析与解决方案

问题背景

在Wanderer项目中，用户报告了一个关于Komoot同步功能的问题。当尝试启用Komoot集成时，系统会持续返回"Invalid credentials"错误。经过深入调查，发现这是由于密码加密机制存在缺陷导致的。

问题根源

核心问题在于集成密钥(密码)被多次加密。具体表现为：

1. 当用户设置Komoot集成时，系统会对密码进行加密存储
2. 在某些情况下，已经加密的密码会被再次加密
3. 这种多重加密导致后续解密过程失败，从而引发认证错误

这个问题不仅影响Komoot集成，同样会影响Strava等其他集成服务。

临时解决方案

开发团队提出了一个临时解决方案，通过添加一个简单的检查机制来判断密钥是否已经被加密：

func LooksLikeEncrypted(s string) bool {
    decoded, err := base64.StdEncoding.DecodeString(s)
    if err != nil {
        return false
    }

    block, err := aes.NewCipher(make([]byte, 32)) // 使用虚拟密钥
    if err != nil {
        return false
    }
    gcm, err := cipher.NewGCM(block)
    if err != nil {
        return false
    }

    nonceSize := gcm.NonceSize()
    return len(decoded) > nonceSize
}

这个函数会检查字符串是否具有加密数据的特征，从而避免对已经加密的数据进行二次加密。

根本原因分析

经过更深入的调查，发现问题的根本原因是Pocketbase框架在处理钩子(hook)请求时的行为发生了变化。具体表现为：

1. 原本系统会在发送数据给客户端前对敏感信息进行脱敏处理
2. 框架更新后，这种脱敏机制失效
3. 导致加密后的数据被发送到客户端
4. 客户端又将这些数据原样发回服务器
5. 服务器再次尝试加密已经加密的数据

最终解决方案

开发团队实施了以下修复措施：

1. 修正了Pocketbase钩子处理逻辑
2. 确保敏感数据在发送给客户端前被正确脱敏
3. 保留了服务器端的二次加密检查作为额外防护层

该修复已在v0.16.1版本中发布。

安全建议

对于类似集成系统的开发，建议：

1. 实现明确的加密状态标记机制
2. 在客户端和服务器端都进行数据验证
3. 对敏感数据的传输过程实施端到端保护
4. 考虑使用专门的密钥管理系统

这种多层防护策略可以有效防止类似加密问题的发生，同时提高系统的整体安全性。

总结

Wanderer项目通过这次问题的解决，不仅修复了Komoot同步功能，还增强了整个集成系统的健壮性。这体现了开源社区通过协作解决问题、持续改进的良好模式，也为其他开发者处理类似加密问题提供了有价值的参考。