Lo que describe es muy similar a la idea detrás de Kerberos, pero no llega a resolver los problemas que Kerberos resuelve.
Saber que tanto AES (A, B) como AES (B, A) sin duda ayudaría a un atacante permitiéndoles probar con autoridad un descifrado válido; si no supieran nada, pero encontraron algunos candidatos para A, B con m1 = AES (A, B), podrían probar que AES (B, A) = m2 donde m2 es el otro mensaje interceptado. Sin embargo, esta es realmente la menor de tus preocupaciones.
Las claves AES tienen que tener una longitud particular. No has mencionado cómo funciona la derivación de tu clave, así que no voy a hablar de eso.
Realmente, el modelo correcto para hacer este tipo de cosas es derivar una clave de la contraseña del usuario en el nodo cliente. El servidor conoce una clave que se puede usar para cifrar los datos de manera que el cliente pueda descifrarlos y, a petición, crea un token de autenticación que envía al solicitante, así cifrado. El token no sirve para nadie que no conozca la clave (privada) del usuario, por lo que es seguro enviarlo a quien sea. Luego el usuario lo descifra y se autentica.
El usuario no necesita enviar inmediatamente este token de vuelta; el servidor puede asumir que quien lo presente está autenticado como el usuario para el que fue emitido.
Ahora, resolveré algunos otros problemas agregando al modelo: la cosa enviada desde el servidor al cliente no es un token, sino otra clave. El usuario, siempre que pueda descifrar la clave, puede usar esa clave para firmar las solicitudes. De esa manera, nada sensible tiene que atravesar la red de forma clara y no hay necesidad de establecer un canal de confianza.
Kerberos lleva esto un paso más allá al permitir que esta clave se use para emitir aún más claves, y tiene algunos otros conceptos, que permiten al usuario iniciar sesión en un lugar para autenticarse en otro. También hay algunos nonces para evitar los ataques de reproducción, y esas cosas. Sin embargo, en la medida en que su solución se desvíe de este modelo, es subóptima.
Lo más destacado aquí es que no desea la contraseña de texto sin formato en ningún lugar, y mucho menos en el servidor, y realmente no necesita enviarla a través de la red o verificarla. Pero, en lugar de rediseñar su sistema para que coincida, solo use uno de los numerosos métodos de autenticación de desafío-respuesta ya implementados, auditados y disponibles.
Los ataques contra su esquema son posibles, pero los ataques en particular dependen de si su token (el gran número al que se refiere) se trata como un nonce, qué tan grande es, cómo obtiene las claves de las contraseñas , cómo trata la contraseña en el servidor, cómo se genera el nonce y algunas otras cosas. La primera línea de ataque que elegiría es predecir el error y usarlo para descifrar la contraseña, validando contra el tráfico en la otra dirección.